ByteballのホワイトペーパーをGoogle翻訳した

Byteballに興味があり、仕組みを理解するためにホワイトペーパーをGoogle翻訳に突っ込みました(私の英語力は小学生以下です)。
日本語情報が少ないようなので、せっかくなのでQiitaに投稿しました。

Google翻訳頼みのためところどころ変な翻訳になっているので、時間のあるときに直したいです。
どなたか英語が堪能な方、ご指摘いただければ時間のあるときに逐一直しますのでコメントにどうぞお願いします。

Byteballリンク

• 公式サイト(英語)
  • https://byteball.org/
• 公式サイト(日本語)
  • https://byteball.org/index.html.ja
• ホワイトペーパー
  • https://byteball.org/Byteball.pdf

以下ホワイトペーパー訳

Abstract

要約

Byteball is a decentralized system that allows tamper proof storage of arbitrary data, including data that represents transferrable value such as currencies, property titles, debt, shares, etc.

Byteballは、財務諸表、財産権、債務、株式などの譲渡可能な価値を表すデータを含む、任意のデータの改ざんのない格納を可能にする分散システムです。

Storage units are linked to each other such that each storage unit includes one or more hashes of earlier storage units, which serves both to confirm earlier units and establish their partial order.

記憶ユニットは、各記憶ユニットが以前の記憶ユニットの1つ以上のハッシュを含み、以前のユニットを確認し、それらの部分的な順序を確立するために役立つように、互いにリンクされる。

The set of links among units forms a DAG (directed acyclic graph).

ユニット間のリンクのセットは、DAG（有向非循環グラフ）を形成する。

There is no single central entity that manages or coordinates admission of new units into the database, everyone is allowed to add a new unit provided that he signs it and pays a fee equal to the size of added data in bytes.

新しいユニットのデータベースへの入場を管理または調整する単一の中央エンティティは存在せず、誰でも新しいユニットを追加することができ、それに署名し、バイト単位の追加データのサイズに等しい料金を支払う。

The fee is collected by other users who later confirm the newly added unit by including its hash within their own units.

手数料は、後で新たに追加されたユニットを、自身のユニット内にハッシュを含めて承認する他のユーザによって収集される。

As new units are added, each earlier unit receives more and more confirmations by later units that include its hash, directly or indirectly.

新しいユニットが追加されると、以前の各ユニットは、直接的または間接的にそのハッシュを含む後のユニットによってますます多くの承認を受け取ります。

There is an internal currency called ‘bytes’ that is used to pay for adding data into the decentralized database.

分散されたデータベースにデータを追加するための支払いに使用される「bytes」と呼ばれる内部通貨があります。

Other currencies(assets) can also be freely issued by anyone to represent property rights, debt, shares, etc.

その他の通貨（資産）は財産権、債務、株式などを誰でも自由に発行することができます。

Users can send both bytes and other currencies to each other to pay for goods/services or to exchange one currency for another; the transactions that move the value are added to the database as storage units.

ユーザーは、商品やサービスの支払いや別の通貨の交換のために、bytesと他の通貨をお互いに送信することができます。値を移動するトランザクションは、記憶ユニットとしてデータベースに追加されます。

If two transactions try to spend the same output (double-spend) and there is no partial order between them, both are allowed into the database but only the one that comes earlier in the total order is deemed valid.

2つのトランザクションが同じ出力（二重支払い）を費やそうとしたときに、それらの間に部分的な順序がない場合、両方がデータベースに入ることができますが、全体の順序で先に来るものだけが有効です。

Total order is established by selecting a single chain on the DAG (the main chain) that is attracted to units signed by known users called witnesses.

全体の順序は、witnessと呼ばれる既知のユーザーによって署名されたユニットに引き付けられるDAG（メインチェーン）上の1つのチェーンを選択することによって確立されます。

A unit whose hash is included earlier on the main chain is deemed earlier on the total order.

ハッシュがメインチェーンの早い方に含まれているユニットは、全体の順序の早い方であるとみなされます。

Users choose the witnesses by naming the user-trusted witnesses in every storage unit.

ユーザーは、すべての記憶ユニットでユーザーの信頼できるwitnessの名前を付けて、witnessを選択します。

Witnesses are reputable users with real-world identities, and users who name them expect them to never try to double-spend.

witnessは、実世界のアイデンティティを持つ評判の高いユーザーです。名前を挙げたユーザーは、二重支払いを試みることは決してありません。

As long as the majority of witnesses behave as expected, all double-spend attempts are detected in time and marked as such.

witnessの大部分が期待通りに行動する限り、全ての二重支出は時間内に検出され、そのようにマークされます。

As witnesses-authored units accumulate after a user’s unit, there are deterministic (not probabilistic) criteria when the total order of the user’s unit is considered final.

witnessが作成したユニットは、ユーザのユニットの後に蓄積されるため、ユーザのユニットの全体の順序が最終的であると判断されると、決定的な（確率的ではない）基準が存在する。

Users store their funds on addresses that may require more than one signature to spend (multisig).

ユーザーは、複数の署名を必要とする可能性のあるアドレスに資金を保管します（マルチシグ）。

Spending may also require other conditions to be met, including conditions that are evaluated by looking for specific data posted to the database by other users (oracles).

支出には、他のユーザー（oracle）がデータベースに投稿した特定のデータを検索することによって評価される条件など、他の条件を満たす必要がある場合もあります。

Users can issue new assets and define rules that govern their transferability.

ユーザーは、新しい資産を発行し、譲渡可能性を管理するルールを定義することができます。

The rules can include spending restrictions such as a requirement for each transfer to be cosigned by the issuer of the asset, which is one way for financial institutions to comply with existing regulations.

ルールには、金融機関が既存の規制を遵守するための1つの方法である、資産の発行者が各譲渡を連署する要件などの支払い制限を含めることができます。

Users can also issue assets whose transfers are not published to the database, and therefore not visible to third parties.

ユーザーは、譲渡がデータベースに公開されず、したがって第三者には見えない資産を発行することもできます。

Instead, the information about the transfer is exchanged privately between users, and only a hash of the transaction and a spend proof (to prevent double-spends) are published to the database.

代わりに、譲渡に関する情報がユーザー間で非公開で交換され、トランザクションのハッシュと（二重支払いを防ぐための）支払い証明書のみがデータベースに公開されます。

1. Introduction

1.はじめに

In Orwell’s 1984, the protagonist Winston Smith works in the Records Department of the Ministry of Truth as an editor, revising historical records, to make the past conform to the ever-changing party line and deleting references to unpersons–people who have been "vaporised," i.e. not only killed by the state but denied existence even in history or memory [1].

オーウェルの1984年に、ウィンストン・スミスの主人公は真実の記録局で編集者として、歴史的記録を改訂し、過去の絶えず変化する公式見解に従い、蒸発した失脚した人たちへの参照を削除している。すなわち、国家によって殺されただけでなく、歴史や記憶においてさえも存在を否定した[1]。

What we present here is data storage that is not rewritable.

ここで提示するものは、書き換えが不可能なデータストレージです。

It is a distributed decentralized database where records can neither be revised nor deleted entirely.

これは、分散型の非集中的データベースであり、レコードを完全には変更も削除もできません。

Bitcoin [2] was the first system to introduce tamper proof records designed for the specific purpose of tracking the ownership of electronic currency units known as bitcoins.

Bitcoin [2]は、ビットコインと呼ばれる電子通貨単位の所有権を追跡する特定の目的のために設計された改ざんのない記録を導入する最初のシステムでした。

In Bitcoin, all transfers of the currency are represented as transactions that are digitally signed by the current owner of the coin, transactions are bundled into blocks, and blocks are linked into a chain (blockchain) secured by proof of work (PoW) that assures that large computing resources have been invested into building the chain.

Bitcoinでは、通貨のすべての譲渡は、コインの現在の所有者によってデジタル署名された取引として表され、取引はブロックにまとめられ、ブロックはチェーンの構築に大規模なコンピューティングリソースが投資され保証された作業証明書（PoW）によって保護されたチェーン（ブロックチェーン）にリンクされます。

Any attempt to rewrite anything contained in the chain would therefore require even larger computing resources than those that have already been expended.

チェーンに含まれているものを書き直そうとすると、既に消費されているものよりも大きなコンピューティングリソースが必要になります。

Soon after Bitcoin appeared, it became clear that this was more than just a trust-free P2P electronic currency.

Bitcoinが登場した直後に、これは単に信頼のいらないP2P電子通貨以上のものであることが明らかになりました。

Its technology became a source of new ideas for solving other problems.

その技術は、他の問題を解決するための新しいアイデアの源となった。

At the same time, Bitcoin’s deficiencies and limitations equally became clear.

同時に、Bitcoinの欠陥と制限も同様に明確になりました。

Byteball is designed to generalize Bitcoin to become a tamper proof storage of any data, not solely transfers of a single electronic currency, and remove some of the most pressing deficiencies that impede a wider adoption and growth of Bitcoin.

単一の電子通貨の譲渡だけでなく、Bitcoinの幅広い採用と成長を阻害する最も重要な欠点を取り除くために、ByteballはBitcoinを一般化してデータの改ざんを防止するストレージになるように設計されています。

Blocks.

ブロック。

In Bitcoin, transactions are bundled into blocks, and blocks are linked into a single chain.

Bitcoinでは、トランザクションはブロックにまとめられ、ブロックは単一のチェーンにリンクされます。

Since the blocks are linked linearly, their spacing in time and their size are optimized for near-synchrony among nodes, so that the nodes can share a new block with each other much faster than it typically takes to generate a new block.

ブロックは線形にリンクされているため、時間間隔とサイズはノード間でほぼ同期するように最適化されているため、ノードは新しいブロックを生成するのに必要な時間よりもはるかに高速に新しいブロックを共有できます。

This ensures that nodes most likely see the same block as the last block, and orphaning is minimized.

これにより、ノードが最後のブロックと同じブロックを参照する可能性が高くなり、孤立が最小限に抑えられます。

As Bitcoin grows, blocks become increasingly unwieldy.

Bitcoinが成長するにつれ、ブロックはますます扱いにくくなります。

They are either capped in size, in which case the growth is also capped, or they take too long to propagate to all nodes of the network, in which case there is greater uncertainty about which block is last, and more resources are wasted on extending chains that would later be orphaned.

それらはサイズが制限されており、その場合には成長も制限されているか、ネットワークのすべてのノードに伝播するのに時間がかかりすぎる。その場合、最後のブロックが不確実であり、チェーンは後で孤立してしまいます。

In Byteball, there are no blocks, transactions are their own blocks, and they need not connect into a single chain.

Byteballでは、ブロックはなく、トランザクションは独自のブロックであり、単一のチェーンに接続する必要はありません

Instead a transaction may be linked to multiple previous transactions, and the whole set of transactions is not a chain but a DAG (directed acyclic graph).

代わりに、トランザクションは複数の以前のトランザクションにリンクされていてもよく、トランザクション全体はチェーンではなく、DAG（有向非循環グラフ）である。

DAG-based designs have received much attention recently [3-5].

DAGベースの設計は最近注目を集めている[3-5]。

Cost.

コスト。

Bitcoin transactions are secure because it is prohibitively expensive to redo all the PoW included in the blocks created after the transaction.

Bitcoinトランザクションは安全です。なぜならトランザクション後に作成されたブロックに含まれるすべてのPoWをやり直すのは非常にコストがかかるためです。

But that also means that it is necessary to pay to build the legitimate PoW that is strong enough to ward off any attackers.

しかし、これはまた、攻撃者を撃退するのに十分なほどの正当なPoWを構築するために支払う必要があることを意味します。

This payment is spent for the electricity required to build the PoW.

この支払いは、PoWを構築するために必要な電力のために費やされます。

What is important to note here, is that this money goes outside the Bitcoin ecosystem – to energy companies – meaning that the community of Bitcoin holders as a whole is bleeding capital.

ここで重要なことは、この資金がBitcoinエコシステムの外に出て行くということです。つまり、Bitcoin所有者のコミュニティ全体が出血しているということです。

In Byteball, there is no PoW, instead we use another consensus algorithm based on an old idea that was known long before Bitcoin.

Byteballでは、PoWはありません。代わりに、Bitcoinよりもずっと前に知られていた古いアイデアに基づいた別のコンセンサスアルゴリズムを使用します。

Finality.

終わりに。

Transaction finality in Bitcoin is probabilistic.

Bitcoinのトランザクションの最終性は確率的です。

There are no strict and simple criteria for when you can say that a transaction will never be reversed.

トランザクションが決して元に戻ってこないと言うことができるときは、厳密かつ単純な基準はありません。

Rather, you can only argue that the probability of a transaction being reversed exponentially decays as more blocks are added.

むしろ、より多くのブロックが追加されるにつれて、逆転されるトランザクションの確率は指数関数的に減少すると主張することができます。

While this concept is perfectly clear to those versed in math, it might be a difficult sell to an average Joe who is used to expecting a black-or-white picture in matters of money ownership.

このコンセプトは数学に精通している人にとっては完全にはっきりしていますが、金銭所有の問題で白か黒の状況を期待している平均的なジョーにとっては難しい売りかもしれません。

To complicate things even further, transaction finality also depends on its amount.

物事をさらに複雑にするために、トランザクションの最終性はその金額にも依存します。

If the amount is small, you can be reasonably sure nobody will try to double-spend against you.

金額が少なければ、誰もあなたに2倍の負担をかけようとはしません。

However, if the amount at stake is greater than the block reward (12.5 BTC at the time of writing), you might speculate that the payer could temporarily rent hashpower to mine another chain of blocks that doesn’t contain the transaction that pays to you.

ただし、賭け金額がブロック報酬（執筆時の12.5 BTC）を上回っている場合は、支払人がハッシュ・パワーを一時的に借りて、あなたに支払うトランザクションを含まないブロックの別のチェーンを採掘することができると推測するかもしれません。

Therefore, you have to wait for more confirmations before being sure enough that a high-value transaction is final.

したがって、価値の高い取引が最終的なものであることを十分に確認する前に、より多くの承認を待たなければなりません。

In Byteball, there are deterministic criteria for when a transaction is deemed final, no matter how large it was.

Byteballには、トランザクションがどれほど大きくても、トランザクションが最終とみなされるときの決定的な基準があります。

Exchange rate.

為替レート。

The Bitcoin price is known to be quite volatile.

Bitcoin価格はかなり変動することが知られています。

The bigger problem is that this price is not only volatile, it is not bound to anything.

より大きな問題は、この価格が変動するだけでなく、何にも縛られないということです。

Share and commodity prices are also very volatile but there are fundamentals behind them.

株式や商品価格も非常に変動するが、その背景には基礎がある。

Share price is largely a function of company earnings, revenue, debt-to-capital ratio, etc.

株式は、主に、会社の収益、収益、負債対資本比率などの関数です。

Commodity prices depend, among other factors, on costs of production with various suppliers.

商品価格は、とりわけ、様々な供給者との生産コストに依存する。

For example, if the oil price falls below the production costs of some suppliers for a long time, these suppliers will eventually shut down, decreasing production and causing the price to go up.

たとえば、原油価格が一部のサプライヤーの生産コストを長期間に渡って下回ると、サプライヤーは最終的に停止し、生産を減少させ、価格を上昇させます。

There is a negative feedback loop.

負のフィードバックループがあります。

In Bitcoin, there are no fundamentals, and no negative feedback.

Bitcoinには基礎はなく、負のフィードバックもありません。

A Bitcoin price of $500 is no more justified than a price of $50,000 or $5 .

Bitcoinの $500 という価格は、 $50,000 または $5 の価格以上に正当化されていません。

If the Bitcoin price moves from where it is now, this movement alone will not > create any economic forces that would push the price back.

Bitcoinの価格が現在の位置から動き出す場合、この動きだけでは価格を押し戻すような経済的な力は生じません。

It’s just wild.

それはただの野生です。

In Byteball, the base currency, bytes, is used to pay for adding data into the Byteball database.

Byteballでは、Byteballデータベースにデータを追加するための支払いに基本通貨（bytes）が使用されます。

You pay 1,000 bytes to add 1Kb of data.

1Kbのデータを追加するために1,000bytesを支払います。

It is a measure of the utility of the storage in this database, and actual users will have their opinion on what is a reasonable price for this.

これは、このデータベース内のストレージの有用性の尺度であり、実際のユーザーは、これに対して妥当な価格であるかについての意見を持ちます。

If the price of byte rises above what you think is reasonable for your needs, you will find ways to store less bytes, therefore you need to buy less bytes, demand decreases, and the price falls.

bytesの価格があなたのニーズに合っていると思われる以上に上がった場合、より少ないbytesを格納する方法を見つけることができるため、bytes数を減らして需要を減らし、価格を下げる必要があります。

This is negative feedback, common for all goods/services whose demand is driven by need, not speculation.

これは負のフィードバックであり、需要が投機的ではなく必要性によって動かされるすべての財/サービスに共通する。

Besides paying in bytes, one can issue other assets and use them as means of payment.

bytes単位での支払いに加えて、他の資産を発行して支払い手段として使用することができます。

These assets might represent, for example, debt expressed in fiat currencies or in natural units (such as kWh or barrels of oil).

これらの資産は、例えば、法定通貨または自然単位（kWhまたは石油のバレルなど）で表された債務を表す場合があります。

The price of such assets is naturally bound to the underlying currencies or commodities.

そのような資産の価格は、当然、基礎となる通貨や商品に結びついています。

Privacy.

プライバシー。

All Bitcoin transactions and balances of all addresses are visible on the blockchain.

すべてのBitcoinトランザクションとすべてのアドレスの残高がブロックチェーン上に表示されます。

Although there are ways to obfuscate one’s transactions and balances, it is not what people have come to expect from a currency.

トランザクションや残高を難読化する方法はありますが、それは人々が通貨から期待しているものではありません。

Transactions in bytes (the base currency) in Byteball are equally visible, but there is a second currency (blackbytes), which is significantly less traceable.

Byteballのbytes単位（基本通貨）でのトランザクションは同じように表示されますが、2番目の通貨（blackbytes）があり、これは追跡可能性が大幅に低下します。

Compliance.

コンプライアンス。

Bitcoin was designed as an anonymous currency where people have absolute control over their money.

Bitcoinは、人々がお金を絶対に支配する匿名通貨として設計されました。

That goal was achieved; however, it made Bitcoin incompatible with existing regulations, and hence inappropriate for use in the financial industry.

その目標は達成された。しかし、Bitcoinは既存の規制と互換性がなく、したがって、金融業界での使用には不適切です。

In Byteball, one can issue assets with any rules that govern their transferability, from no restrictions at all, like Bitcoin, to anything like requiring every transfer to be cosigned by the issuer (e.g. the bank) or restricted to a limited set of whitelisted users.

Byteballでは、Bitcoinのような制限なしに、発行者（銀行など）によってすべての転送が要求されるか、ホワイトリストに登録された限られたユーザーのみに制限されるようなものに、譲渡性を支配するルールを持つ資産を発行することができます。

2. Database structure

2.データベース構造

When a user wants to add data to the database, he creates a new storage unit and broadcasts it to his peers.

ユーザーは、データベースにデータを追加したいときに、新しいストレージユニットを作成し、それをピアにブロードキャストします。

The storage unit includes (among other things):

ストレージユニットは、（とりわけ）以下を含む。

• The data to be stored. A unit may include more than one data package called a message. There are many different types of messages, each with its own structure. One of the message types is payment, which is used to send bytes or other assets to peers.
• Signature(s) of one or more users who created the unit.Users are identified by their addresses. Individual users may (and are encouraged to) have multiple addresses, like in Bitcoin. In the simplest case, the address is derived from a public key, again similar to Bitcoin.
• References to one or more previous units (parents) identified by their hashes.

•保存するデータ。ユニットには、メッセージと呼ばれる複数のデータパッケージを含めることができます。メッセージにはさまざまな種類があり、それぞれに独自の構造があります。メッセージタイプの1つは支払いで、これはバイトまたは他のアセットをピアに送信するために使用されます。
• ユニットを作成した1人以上のユーザーの署名。ユーザーはアドレスで識別されます。個々のユーザーは、Bitcoinのように複数のアドレスを持つことができます（そして推奨されます）。最も単純なケースでは、アドレスはBitcoinに似ている公開鍵から得られます。
• ハッシュで識別された1つ以上の以前のユニット（親）への参照。

References to parents is what establishes the order (only partial order so far) of units and generalizes the blockchain structure.

親への参照は、ユニットの順序（これまでの部分順序のみ）を確立し、ブロックチェーン構造を一般化するものです

Since we are not confined to one-parent–one-child relationships between consecutive blocks, we do not have to strive for near-synchrony and can safely tolerate large latencies and high throughputs:

連続ブロック間の親子関係に限定されているわけではないので、ほぼ同期するように努力する必要はなく、大きな待ち時間と高いスループットにも安全に対応できます。

we’ll just have more parents per unit and more children per unit.

ユニットあたりの親が多く、ユニットあたりの子どもが多くなります。

If we go forward in history along parent-child links, we’ll observe many forks when the same unit is referenced by multiple later units, and many merges when the same unit references multiple earlier units (developers are already used to seeing this in git).

履歴の中で親子リンクに沿って進むと、同じユニットが複数の後のユニットによって参照されるとき、多くのフォークが観察され、同じユニットが複数の前のユニットを参照するときに多くのマージが行われます
（開発者はすでにgitでこれを見るのに慣れています）。

This structure is known in graph theory as directed acyclic graph (DAG).

この構造は、有向非循環グラフ（DAG）としてグラフ理論で知られている。

Units are vertices, and parent-child links are the edges of the graph.

ユニットは頂点で、親子リンクはグラフの端です。

Figure 1. Storage units connected into a DAG.
Arrows are from child to parent, G is the genesis unit.

図1. DAGに接続されたストレージユニット。
矢印は子供から親まで、Gはジェネシスユニットです。

In the special case when new units arrive rarely, the DAG will look almost like a chain, with only occasional forks and quick merges.

新しいユニットがまれにしか届かない特殊なケースでは、DAGは鎖のように見えますが、時折のフォークと速いマージがあります。

Like in blockchains where each new block confirms all previous blocks (and transactions therein), every new child unit in the DAG confirms itsparents, all parents of parents, parents of parents of parents, etc.

各新しいブロックがすべての前のブロック（およびその中のトランザクション）を確認するブロックチェーンの場合と同様に、DAG内のすべての新しい子ユニットは、その親、親のすべての親、親の親の親などを確認する。

If one tries to edit a unit, he will also have to change its hash.

ユニットを編集しようとすると、ハッシュも変更する必要があります

Inevitably, this would break all child units who reference this unit by its hash as both signatures and hashes of children depend on parent hashes.

必然的に、これは、このユニットを参照するすべての子ユニットをハッシュで分割します。これは、子ハッシュの署名とハッシュの両方が親ハッシュに依存するためです。

Therefore, it is impossible to revise a unit without cooperating with all its children or stealing their private keys.

したがって、すべての子どもと協力したり、秘密鍵を盗み出すことなく、ユニットを改訂することは不可能です。

The children, in turn, cannot revise their units without cooperating with their children (grandchildren of the original unit), and so on.

子供たちは、子供たち（元のユニットの孫たち）と協力せずに、彼らのユニットを改訂することはできません。

Once a unit is broadcast into the network, and other users start building their units on top of it (referencing it as parent), the number of secondary revisions required to edit this unit hence grows like a snowball.

あるユニットがネットワークにブロードキャストされ、他のユーザがそのユニットをその上に構築する（親として参照する）ようになると、このユニットを編集するのに必要なセカンダリリビジョンの数は雪玉のように増加します。

That’s why we call this design Byteball (our snowflakes are bytes of data).

だから我々はこのデザインByteball（私たちの雪片はデータのバイトです）と呼んでいます。

Unlike blockchains where issuing a block is a rare event and only a privileged caste of users is in practice engaged in this activity, in a new Byteball unit starts accumulating confirmations immediately after it is released and confirmations can come from anyone, every time another new unit is issued.

ブロックの発行がまれなイベントであり、特権階級のユーザだけが実際にこの活動に従事しているブロックチェーンとは異なり、新しいByteballユニットでは、リリース直後に承認の蓄積が開始され、別の新しいユニット発行されます。

There is no two-tier system of ordinary users and miners.

普通のユーザーとマイナーの2層システムはありません。

Instead, users help each other: by adding a new unit its author also confirms all previous units.

代わりに、ユーザーはお互いを助けます。新しいユニットを追加することによって、作者は以前のすべてのユニットも承認​​します。

Unlike Bitcoin, where an attempt to revise a past transaction requires a large computational effort, an attempt to revise a past record in Byteball requires coordination with a large and growing number of other users, most of whom are anonymous strangers.

過去の取引を修正しようとする試みが大きな計算量を必要とするBitcoinとは異なり、Byteballの過去のレコードを修正しようとする試みには、匿名の見知らぬ人である他の多くのユーザーとの調整を必要とします。

The immutability of past records is therefore based on the sheer complexity of coordinating with such a large number of strangers, who are difficult to reach, have no interest in cooperation, and where every single one of them can veto the revision.

したがって、過去の記録の不変性は、到達するのが難しく、協力に関心がなく、すべての人が改訂を拒否することができるような多数の見知らぬ人と調整するという単純な複雑さに基づいています。

By referencing its parents, a unit includes the parent.

その親を参照することによって、ユニットには親が含まれます。

It doesn’t include the full content of the parent; rather, it depends on its information through the parent’s hash.

親の完全な内容は含まれていません。むしろ、親のハッシュによる情報に依存します

In the same way, the unit indirectly depends on and therefore includes the parents of the parent, their parents, and so on, and every unit ultimately includes the genesis unit.

同じように、ユニットは間接的に依存するため、親の親、その親などを含み、すべてのユニットは最終的にジェネシスユニットを含む。

There is a protocol rule that a unit cannot reference redundant parents – that is such parents that one parent includes another.

ユニットが冗長な親を参照することができないプロトコルルールがあります。つまり、ある親が別の親を含むような親です。

For example, if unit B references unit A, then unit C cannot reference both units A and B at the same time.

例えば、ユニットBがユニットAを参照する場合、ユニットCはユニットAとユニットBの両方を同時に参照することはできない。

A is already, in a way, contained within B.

Aは既にB内に含まれています。

This rule removes unnecessary links that don’t add any new useful connectivity to the graph.

このルールは、グラフに新しい有用な接続を追加しない不要なリンクを削除します。

3. Native currency:bytes

3.ネイティブ通貨：バイト

Next, we need to introduce some friction to protect against spamming the database with useless messages.

次に、役に立たないメッセージでデータベースにスパミングするのを防ぐために摩擦を導入する必要があります。

The barrier to entry should roughly reflect the utility of storage for the user and the cost of storage for the network.

エントリの障壁は、ユーザのストレージの実用性とネットワークのストレージコストを大まかに反映する必要があります。

The simplest measure for both of these is the size of the storage unit.

これらの両方のための最も簡単な手段は、ストレージユニットのサイズです。

Thus, to store your data in the global decentralized database you have to pay a fee in internal currency called bytes, and the amount you pay is equal to the size of data you are going to store (including all headers, signatures, etc).

したがって、グローバル分散データベースにデータを格納するには、bytesと呼ばれる内部通貨で料金を支払う必要があります。支払う金額は、保存するデータのサイズ（すべてのヘッダー、署名などを含む）と同じです。

Similar to pound sterling, which was equal to one pound of silver when it was first introduced, the name of the currency reflects its value.

それが最初に導入されたときに銀1ポンドに等しいポンド・スターリングと同様に、通貨の名前はその価値を反映しています。

To keep the incentives aligned with the interests of the network, there is one exception in size calculation rules.

インセンティブをネットワークの利益に合わせるために、サイズ計算ルールには例外が1つあります。

For the purposes of calculating unit size, it is assumed that the unit has exactly two parents, no matter the real number.

ユニットのサイズを計算するために、実数にかかわらず、ユニットに厳密に2つの親があると仮定します。

Therefore, the size of two hashes of parent units is always included in the unit size.

したがって、親ユニットの2つのハッシュのサイズは常にユニットサイズに含まれます

This exception ensures that users will not try to include just one parent in an effort to minimize cost.

この例外は、ユーザーがコストを最小限に抑えるために1人の親だけを含めることを試みないようにします。

The cost is the same no matter how many parents are included.

親がいくつ含まれても、費用は同じです

To keep the DAG as narrow as possible, we incentivize users to include as many parents as possible (as mentioned before, this does not negatively affect payable size), and as recent parents as possible, by paying part of the unit’s fees to those who are first to include it as a parent.

ユニットの手数料の一部を、親として最初に含めた人に支払うことでユーザーにインセンティブを与えます。
そして私たちはできるだけ多くの親（前述のように、これは支払い可能なサイズに悪影響を及ぼさない）をできるだけ最近の親として含め、DAGを可能な限り狭くします。

We’ll define later what exactly is ‘first’.

私たちは後で正確に「最初のもの」を定義します。

Bytes can be used not only for payment of storage fees (also called commissions), but also can be sent to other users to pay for goods or services or in exchange for other assets.

bytesは、ストレージ手数料（手数料とも呼ばれる）の支払いのためだけでなく、商品やサービスの支払いや他の資産との交換のために他のユーザーに送信することもできます。

To send a payment, the user creates a new unit that includes a payment message such as the following (from now on, we use JSON to describe data structures):

支払いを送信するために、ユーザーは次のような支払いメッセージを含む新しいユニットを作成します（これからはJSONを使用してデータ構造を記述します）。

{
    inputs: [
        {
            unit: "hash of input unit",
            message_index: 2, // index of message where this utxo
            was created
            output_index: 0 // index of output where this utxo
            was created
        },
        …
    ],
    outputs: [
        {
            address: "RECEIVER ADDRESS",
            amount: 15000 // in bytes
        },
        …
    ]
}

The message contains:
• An array of outputs: one or more addresses that receive the bytes and the amounts they receive.
• An array of inputs: one or more references to previous outputs that are used to fund the transfer.
These are outputs that were sent to the author address(es) in the past and are not yet spent.

メッセージには以下が含まれます：
• 出力の配列：バイトを受信する1つ以上のアドレスと受信した量。
• 入力の配列：転送の資金調達に使用される以前の出力への1つ以上の参照。
これらは、過去の作者のアドレスに送信され、まだ使われていない出力です。

The sum of inputs should be equal to the sum of outputs plus commissions (input amounts are read from previous outputs and are not explicitly indicated when spending).

入力の合計は、出力と手数料の合計（入力量は以前の出力から読み込まれ、支出時には明示されていません）と等しくなければなりません。

The unit is signed with the author’s private keys.

ユニットは作者の秘密鍵で署名されています。

The total number of bytes in circulation is 1015, and this number is constant.

循環中の総bytes数は1015であり、この数は一定です。

All bytes are issued in the genesis unit, then transferred from user to user.

すべてのbytesはジェネシスユニットで発行され、ユーザからユーザに転送されます。

Fees are collected by other users who help to keep the network healthy (more details about that later), so they stay in circulation.

料金は、ネットワークの健全性を維持するのに役立つ他のユーザーによって収集されます（詳細は後で詳しく説明します）。

The number 1015 was selected as the largest round integer that can be represented in JavaScript.

1015という数字は、JavaScriptで表現できる最大の整数です。

Amounts can only be only integers.

金額は整数だけです。

Larger units of the currency are derived by applying standard prefixes: 1 kilobyte (Kb) is 1,000 bytes, 1 megabyte (Mb) is 1 million bytes, etc.

1キロバイト（Kb）は1,000バイト、1メガバイト（Mb）は100万バイトなどの標準プレフィックスを適用することによって、より大きな単位の通貨が得られます。

4. Double-spends

1. 二重支払い

If a user tries to spend the same output twice, there are two possible situations:

ユーザーが同じ出力を2回使用しようとすると、次の2つの状況が発生する可能性があります。

1. There is partial order between the two units that try to spend the same output, i.e. one of the units (directly or indirectly) includes the other unit, and therefore comes after it. In this case, it is obvious that we can safely reject the later unit.
2. There is no partial order between them. In this case, we accept both. We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid.

1.同じ出力を使用しようとする2つのユニット間に部分的な順序があります。つまり、一方のユニットに（直接的または間接的に）もう一方のユニットが含まれているため、そのユニットの後に来ます。この場合、後のユニットを安全に拒否できることは明らかです。
2.それらの間に部分的な順序はありません。この場合、我々は両方を受け入れる。私たちは、新しいユニットの下に十分に深く埋まっているときに、ユニットの間で総秩序を確立します（以下の方法を参照してください）。トータルオーダーで早期に表示されているものは有効とみなされ、他方は無効とみなされます。

There is one more protocol rule that simplifies the definition of total order.

トータルオーダーの定義を簡素化するプロトコル規則がもう1つあります。

We require, that if the same address posts more than one unit, it should include (directly or indirectly) all its previous units in every subsequent unit, i.e. there should be partial order between consecutive units from the same address.

同じアドレスが複数のユニットをポストする場合は、それ以降のすべてのユニットに前のすべてのユニットを（直接的または間接的に）含める必要があります。

In other words, all units from the same author should be serial.

言い換えれば、同じ著者のすべてのユニットは連続的でなければなりません。

If someone breaks this rule and posts two units such that there is no partial order between them (nonserial units), the two units are treated like double-spends even if they don’t try to spend the same output.

誰かがこのルールを破って、2つのユニットの間に部分的な順序（非直列ユニット）がないようにポストすると、2つのユニットは、同じ出力を費やそうとしなくても、二重支払いのように扱われます。

Such nonserials are handled as described in situation 2 above.

そのような非直列は、上記の状況2で説明したように処理されます。

Figure 2. Double-spends. There is no partial order between them.

図2.二重支払い。それらの間に部分的な順序はありません。

If a user follows this rule but still tries to spend the same output twice, the double-spends become unambiguously ordered and we can safely reject the later one as in situation 1 above.

ユーザーがこのルールに従っても、同じ出力を2回使用しようとすると、二重支出は明白に発注され、上記の状況1のように後の支払いを安全に拒否できます。

The double-spends that are not nonserials at the same time are hence easily filtered out.

同時に非直列ではない二重支払いは容易に除外されます。

This rule is in fact quite natural.

このルールは実際には非常に自然です。

When a user composes a new unit, he selects the most recent other units as parents of his unit.

ユーザーが新しいユニットを作成すると、そのユニットの親として直近の他のユニットが選択されます。

By putting them on his parents list, he declares his picture of the world, which implies that he has seen these units.

親のリストに載せて、彼は世界の彼の絵を宣言します。これは彼がこれらのユニットを見たことを意味します。

He has therefore seen all parents of parents, parents of parents of parents, etc up until the genesis unit.

したがって、彼は親の親、親の親の親などをジェネシスユニットまで見てきました。

This huge set should obviously include everything that he himself has produced, and therefore has seen.

この巨大なセットには、明らかに彼自身が生産したすべてのものが含まれているはずです。

By not including a unit (even indirectly, through parents) the user denies that he has seen it.

ユニットを（親を介して間接的に）含めないことによって、ユーザは彼がそれを見たことを否定する。

If we see that by not including his own previous unit a user denies having seen it, we’d say it’s odd, something fishy is going on.

自分の前のユニットを含めないことで、ユーザーがそれを見たことを否定すると、それは奇妙なことだと思います。

We discourage such behavior.

私たちはそのような行動を阻止します。

5. The main chain

1. メインチェーン

Our DAG is a special DAG.

私たちのDAGは特別なDAGです。

In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction.

通常の使用では、人々はほとんど新しいユニットをわずかに新しいユニットにリンクします。つまり、DAGは一方向にしか成長しません。

One can picture it as a thick cord with many interlaced wires inside.

内部に多くのインターレースされたワイヤーを持つ太いコードとして描写することができます。

This property suggests that we could choose a single chain along child-parent links within the DAG, and then relate all units to this chain.

このプロパティは、DAG内の子 - 親リンクに沿って1つのチェーンを選択し、すべてのユニットをこのチェーンに関連付けることができることを示しています。

All the units will either lie directly on this chain, which we’ll call the main chain, or be reachable from it by a relatively small number of hops along the edges of the graph.

すべてのユニットは、このチェーン上に直接横たわっているか、またはメインチェーンと呼ばれているか、またはグラフの端に沿って比較的少数のホップで到達可能です。

It’s like a highway with connecting side roads.

それは、道路を結ぶ高速道路のようなものです。

One way to build a main chain is to develop an algorithm that, given all parents of a unit, selects one of them as the “best parent”.

メインチェーンを構築する1つの方法は、ユニットのすべての親が与えられれば、それらのうちの1つを「最良の親」として選択するアルゴリズムを開発することである。

The selection algorithm should be based only on knowledge available to the unit in question, i.e. on data contained in the unit itself and all its ancestors.

選択アルゴリズムは、問題のユニットに利用可能な知識、すなわちユニット自体および、そしてすべての祖先に含まれるデータにのみ基づいていなければならない。

Starting from any tip (a childless unit) of the DAG, we then travel backwards in history along the best parent links.

DAGの任意のヒント（子なしのユニット）から始めて、最良の親リンクに沿って履歴内を後方に移動します。

Traveling this way, we build a main chain and eventually arrive at the genesis unit.

このようにして、私たちはメインチェーンを作り、最終的にジェネシスユニットに到着します。

Note that the main chain built starting from a specific unit will never change as new units are added.

特定のユニットから開始して構築されたメインチェーンは、新しいユニットが追加されると決して変更されないことに注意してください。

This is because on each step we are traveling from child to parent, and an existing unit can never acquire new parents.

これは、各ステップにおいて、私たちは子から親に移動しており、既存のユニットは決して新しい親を得ることができないからです。

If we start from another tip, we’ll build another main chain.

別のヒントから始めれば、別のメインチェーンを構築します。

Of note here is that if those two main chains ever intersect while they go back in history, they will both go along the same path after the intersection point.

ここで注目すべき点は、履歴の中に戻る間に2本のメインチェーンが交差すると、交差点の後に同じ経路をたどることです。

In the worst case, the main chains will intersect only in genesis.

最悪の場合、メインチェーンは起源においてのみ交叉します。

Given that the process of unit production is not coordinated among users, however, one might expect to find a class of main chains that do converge not too far from the tips.

しかし、ユニット生産のプロセスがユーザー間で調整されていないとすれば、ヒントから離れすぎないように収束するメインチェーンのクラスを見つけることが期待されるかもしれません。

Figure 3. Main chains built from different childless units intersect and then go along the same path.

図3.異なる子なしのユニットから構築されたメインチェーンは交差し、同じパスに沿って移動します。

Of the two double-spends, the one with the lower main chain index (5) wins, while the other (with MCI=6) is deemed invalid.

2回の二重支払いのうち、より低いメインチェーンインデックス（5）のものが勝ち、他方（MCI(たぶんメインチェーンインデックス) = 6の場合）は無効とみなされる。

Once we have a main chain (MC), we can establish a total order between two conflicting nonserial units.

メインチェーン（MC）を獲得すると、2つの相反する非直列ユニットの間で全体の順序を確立することができます。

Let’s first index the units that lie directly on the main chain.

メインチェーンに直接横たわるユニットの最初のインデックスを作ってみましょう。

The genesis unit has index 0, the next MC unit that is a child of genesis has index 1, and so on traveling forward along the MC we assign indexes to units that lie on the MC.

ジェネシスユニットはインデックス0を持ち、ジェネシスの子である次のメインチェーンユニットはインデックス1を持ち、メインチェーンに沿って進むと、メインチェーンにあるユニットにインデックスを割り当てます。

For units that do not lie on the MC, we can find an MC index where this unit is first included (directly or indirectly).

メインチェーン上にないユニットについては、このユニットが最初に（直接的または間接的に）含まれるメインチェーンインデックスを見つけることができます。

In such a way, we can assign an MC index (MCI) to every unit.

このようにして、すべてのユニットにメインチェーンインデックス（MCI）を割り当てることができます。

Then, of the two nonserials, the one that has a lower MCI is considered to come earlier and deemed valid, while the other is invalid.

次に、2つの非直列のうち、より低いMCIを有するものが早期に有効であると考えられ、他方は無効であると考えられる。

If both nonserials happen to have the same MCI, there is tiebreaker rule that the unit with the lower hash value (as represented in base64 encoding) is valid.

両方の非直列が同じMCIを持つ場合、下位ハッシュ値を持つユニット（base64エンコーディングで表される）が有効であるというタイブレーカールールがあります。

Note that we keep all versions of the double-spend, including those that eventually lose.

最終的に失うものも含め、すべてのバージョンの二重支払いを維持しています。

DagCoin [3] was the first published work that suggested storing all conflicting transactions and deciding which one to treat as valid.

DagCoin [3]は、競合するすべてのトランザクションを格納し、どちらを有効として扱うかを決定する最初の公開された作業でした。

The MC built from a specific unit tells us what this unit’s author thinks about the order of past events, i.e. his point of view about the history.

特定のユニットから構築されたメインチェーンは、過去の出来事の順序、すなわち履歴に関する彼の視点について、このユニットの作者がどのように考えるかを教えてくれます。

The order then implies which nonserial unit to consider valid, as described above.

順序は、上記のように、どの非直列ユニットが有効であると考えられるかを含意する。

Note that by choosing the best parent among all parents of a given unit, we are simultaneously making a choice among their MCs: the MC of the unit in question will be the MC of its best parent extended forward by one link.

特定のユニットのすべての親の中から最良の親を選択することによって、メインチェーンの中から同時に選択していることに注意してください：問題のユニットのメインチェーンは、1つのリンクで前方に拡張された親のメインチェーンです。

Recognizing that many (or even all) parent units might be created by an attacker, and remembering that the choice of best parent is essentially the choice among versions of history, we should require from our best parent selection algorithm that it favors histories that are “real” from the point of view of the child unit.

多くの（またはすべての）親ユニットが攻撃者によって作成され、最良の親の選択は本質的に履歴のバージョン間の選択であることを覚えているので、親の選択アルゴリズムから、子ユニットの観点から「本当」である。

We hence need to devise a “reality test” that our algorithm would run against all candidate MCs to select the one that scores best.

したがって、私たちのアルゴリズムがすべての候補メインチェーンに対して最高のスコアを選択するために実行する「現実テスト」を考案する必要があります。

6. Witnesses

1. 証人

Looking for a “reality test”, observe that some of the participants of our network are non-anonymous reputable people or companies who might have a long established reputation, or they are businesses interested in keeping the network healthy.

「現実のテスト」を探して、私たちのネットワークの参加者の中には、匿名ではない評判の高い人や、長い間確立された評判を持つ企業や、ネットワークを健康に保つことに関心のある企業であることを観察してください。

We’ll call them witnesses.

私たちは彼らをwitnessと呼ぶでしょう。

While it is reasonable to expect them to behave honestly, it is also unreasonable to totally trust any single witness.

彼らが正直に行動することを期待することは合理的ですが、単一のwitnessを完全に信頼することは不合理です。

If we know the Byteball addresses of several witnesses, and also expect them to post frequently enough, then to measure the reality of a candidate MC one might travel along the MC back in time and count the witness-authored units (if the same witness is encountered more than once, he is not counted again).

複数のwitnessのByteballアドレスを知り、頻繁に投稿することを期待している場合は、候補MCの現実を測定するためにMCに沿って時間通りに移動し、witness作成ユニットを数えます（同じwitnessが2回以上遭遇した場合、彼は再びカウントされない）。

We would stop traveling as soon as we had encountered the majority of witnesses.

大多数のwitnessに会うとすぐに、私たちは移動をやめるでしょう。

We would then measure the length of the longest path on the graph from the point at which we stopped to the genesis.

次に、グラフ上の最長経路の長さを、停止した時点から起点まで測定します。

We’ll call this length the level of the unit where we stopped, and the witnessed level of the parent whose MC we are testing.

この長さを、停止したユニットのレベルと、MCをテストしている親の証明されたレベルと呼びます。

The candidate MC that yields the greater witnessed level is considered more “real”, and the parent bearing this MC is selected as best parent.

より大きな証明されたレベルをもたらす候補MCは、より「現実」と考えられ、このMCを有する親は、最良の親として選択される。

In case there are several contenders with a maximum witnessed level, we would select the parent whose own level is the lowest.

証明されたレベルが最大の競争者が複数いる場合は、自分のレベルが最も低い親を選択します。

If the tie persists, we would select the parent with the smallest unit hash (in base64 encoding).

互角が続く場合は、（Base64エンコーディングで）最小のユニットハッシュで親を選択します。

This algorithm allows the selection of the MC that gravitates to units authored by witnesses, and the witnesses are considered to be representative of reality.

このアルゴリズムは、witnessによって作成されたユニットに引き寄せられるMCを選択することを可能にし、witnessは現実を代表するものとみなされる。

If, for example, an attacker forks from the honest part of the network and secretly builds a long chain of his own units (shadow chain), one of them containing a double-spend, and later merges his fork back into the honest DAG, the best parent selection algorithm at the merger point will choose the parent that drives the MC into the honest DAG, as this is where the witnesses were active.

たとえば、攻撃者がネットワークの信頼できる部分から分岐し、秘密に自分のユニット（シャドウチェーン）の長いチェーンを構築している場合、そのうちの1つは二重支払を含み、後で信頼できるDAGに分岐をマージし、合併ポイントでの最良の親選択アルゴリズムは、MCを信頼できるDAGに誘導する親を選択します。これは、witnessがアクティブだった場所です。

The witnesses were not able to post into the shadow chain simply because they didn’t see it before the merger.

witnessは、合併前に見たわけではないため、シャドウチェーンに投稿できませんでした。

This selection of MC reflects the order of events as seen by the witnesses and the user who appointed them.

このMCの選択は、witnessとそれを任命したユーザーが見たイベントの順序を反映しています。

After the attack is over, the entire shadow chain will land on the MC at one point, and the double-spend.

攻撃が終了すると、シャドウチェーン全体が一点でMCに上がり、二重に消費されます。

Figure 4. When an attacker rejoins his shadow DAG into the lit DAG, his units lose competition to become best parent as the choice favors those paths that have more witnesses (marked with w).

図4.攻撃者が影のDAGを光のDAGに再び参加させると、彼のユニットは、より多くのwitness（wとマークされている）がいる選択肢が優先されるので、最適な親になるための競争を失います。

contained in the shadow chain will be deemed invalid because its valid counterpart comes earlier, before the merger point.

シャドウチェーンに含まれる有効なカウンターパートは、合併ポイントの前に早期に来るため、無効と見なされます。

This example shows why the majority of witnesses has to be trusted to post only serially.

この例は、witnessの大半が、逐次に投稿するだけで信頼されなければならない理由を示しています。

The majority should not collude with the attacker and post on his shadow chain.

大多数は、攻撃者と共謀してシャドウチェーンに投稿してはいけません。

Note that we trust the witnesses only to be signs of reality and to not post nonserial units on any shadow chains.

私たちはwitnessが現実の兆候であることを信じているだけで、シャドウチェーン上に非直列ユニットを置かないようにしています。

We are not giving any of them control over the network or any part thereof.

私たちは、彼らにネットワークまたはその一部を支配させてはいません。

Even for this small duty, it is users who appoint the witnesses and they can change their decisions at any time.

この小さな義務でも、witnessを任命するのはユーザーであり、いつでも意思決定を変更することができます。

The idea of looking at some known entity as a sign of reality is not new.

現実の兆候として知られている実体を見るという考えは、新しいものではありません。

It has long been known, and some companies have engaged in such activity, that to prove that some data existed before a specific date, one can hash the data and publish the hash in some hard-to-modify and widely witnessed media, like printed newspaper [6].

それは長い間知られており、特定の日付以前にデータが存在していたことを証明するために、印刷された新聞のような修正が困難で広く目に見えるメディアにデータをハッシュして公開する企業もあります。

Witnesses in Byteball serve the same function as the newspaper.

Byteballのwitnessは新聞と同じ機能を果たします。

Like newspapers, they are well known and trusted.

新聞のように、彼らはよく知られており、信頼されています。

As for newspapers where trust is limited to trusting them to publish the data they are given, witnesses in Byteball are only trusted to post serially, and not much more.

信頼が与えられたデータを公開することに信頼が限定されている新聞に関しては、Byteballのwitbessは逐次投稿するだけで信頼できるものであり、あまり多くはない。

Like newspapers, witnesses don’t know what’s behind the hashes they are witnessing and have few reasons to care.

新聞のように、witnessは証明しているハッシュの背後にあるものを知らず、気にする理由もほとんどありません。

Newspapers are hard to modify (but possible, and in 1984 they do it), while everything produced by witnesses is protected by digital signatures, which makes any modifications impossible.

新聞は修正が難しい（ただし、1984年に可能である）が、witnessによって作成されたものはすべてデジタル署名によって保護されているため、修正が不可能である。

For reliability, we have several witnesses, not just one, and for speed and convenience, these are online.

信頼性のために、私たちには複数のwitnessがいますが、スピードと利便性のためにオンラインです。

Having decided on a list of witnesses, we can then select best the parent and the corresponding history that best fits the definition of reality as “somewhere where these witnesses live”.

witnessのリストを決めたら、現実の定義に最も適した親とそれに対応する履歴を「これらのwitnessが生きるどこか」と選択することができます。

At the same time, the parents themselves might have different witness lists and consequently different definitions of reality.

同時に、親自身が異なるwinessリストを持ち、結果として現実の異なる定義を持つ可能性があります。

We want the definitions of reality, and histories that follow from them, to converge around something common.

私たちは、現実の定義とそれに続く履歴が何か共通のものに収束することを望んでいます。

To achieve this, we introduce the following additional protocol rule.

これを達成するために、以下の追加のプロトコルルールを導入する。

The “near-conformity rule”: best parents must be selected only among those parents whose witness list differs from the child’s witness list by no more than one mutation.

「準拠ルール」：最良の親は、witnessリストが子のwitnessリストと1つだけの突然変異で異なる親の中から選択されなければならない。

This rule ensures that witness lists of neighboring units on the MC are similar enough, therefore their histories mostly agree with one another.

このルールは、MC上の隣接ユニットのwitnessリストが十分に似ていることを保証するため、その履歴はお互いにほとんど一致します。

The parents whose witness list differs by 0 or 1 mutation will be called compatible (with the unit that includes them directly), while the others are incompatible.

witnessリストが0または1の突然変異によって異なる親は、（それらを直接含むユニットとの）互換性と呼ばれ、他のものは互換性がない。

Incompatible parents are still permitted, but they have no chance of becoming best parent.

互換性のない親は引き続き許可されていますが、最良の親になる機会はありません。

If there are no compatible potential parents among childless units (an attacker could flood the network with his units that carry a radically different witness list), one should select parents from older units.

子のいないユニットの中に互換性のある親がない場合（攻撃者は根本的に異なるwitnessリストを持つユニットにネットワークを溢れさせる可能性があります）、古いユニットから親を選択する必要があります。

The above means that each unit must list its witnesses so that they can be compared.

上記のことは、各ユニットがそのwitnessを比較できるように記載しなければならないことを意味します。

We require that the number of witnesses is exactly 12.

witnessの数は正確に12人でなければなりません。

This number 12 was selected because:

12という数は次の理由で選択されました。

• it is sufficiently large to protect against the occasional failures of a few witnesses (they might prove dishonest, or be hacked, or go offline for a long time, or lose their private keys and go offline forever);
• it is sufficiently small that humans can keep track of all the witnesses to know who is who and change the list when necessary;
• the one allowed mutation is sufficiently small compared with the 11 unchanged witnesses.

• 少数のwitnessの時折の不具合から保護するのに十分な大きさである（正当でないと判明したり、ハッキングされたり、長い間オフラインになったり、秘密鍵を失い、永久にオフラインになる可能性があります）。
• 人間が誰であるかを知り、必要に応じてリストを変更するために、すべてのwitnessを追跡することができるほど十分に小さい。
• 許可された1つの突然変異は、11人の変更されていないwitnessと比較して、十分に小さい。

In case a user thinks that any of the witnesses has lost his credibility, or there are just better candidates, the user can replace the witness with a new witness in his list, bearing in mind that his witness list may not differ from that of other units by more than one position.

ユーザーがwitnessのいずれかが信頼性を失ったと思った場合、またはより良い候補者がいる場合、ユーザーはwitnessをリスト内の新しいwitnessに置き換えることができます。彼のwitnessのリストは、複数の位置で他の部署のそれと異なることはないことを心に留めておく。

This means that any changes can happen only gradually, and a general consensus is required for a change bigger than one position.

これは、変化は徐々にしか起こり得ないことを意味し、1つの位置より大きな変化に対しては一般的な合意が必要である。

7. Finality

7.最終

As new units arrive, each user keeps track of his current MC which is built as if he were going to issue a new unit based on all current childless units.

新しいユニットが到着すると、各ユーザは現在のすべての子なしユニットに基づいて新しいユニットを発行するかのように構築された現在のMCを追跡します。

The current MC may be different at different nodes because they may see different sets of childless units.

現在のMCは、異なるセットの子なしのユニットを見ることができるので、異なるノードで異なる可能性がある。

We require that the current MC be built without regard of witness lists, i.e. the user’s own witness list doesn’t matter and even incompatible parents can be selected as best parents.

現在のMCは、witnessリストに関係なく構築される必要があります。つまり、ユーザー自身のwitnessリストは重要ではなく、互換性のない親でも最良の親として選択することができます。

That means that if two users have the same set of childless units, but have different witness lists, their current MCs will still be 12 identical.

つまり、2人のユーザーが同じ子なしユニットのセットを持っていても、異なるwitnessリストを持っている場合、現在のMCは同じ12になります。

The current MC will constantly change as new units arrive.

新しいユニットが到着すると、現在のMCは常に変化します。

However, as we are about to show, a part of the current MC that is old enough will stay invariant.

しかし、私たちがショーをしようとしているように、十分に古い現在のMCの一部は不変のままです。

We expect witnesses (or rather the majority thereof) to behave honestly, therefore necessarily include their previous unit in the next unit authored by the same witness.

私たちはwitness（またはその大多数）が正直に行動することを期待します。したがって、必ず同じwitnessによって作成された次のユニットに前のユニットを含めるようにしてください。

This means that when a witness composes a new unit, only recent units are candidates to be chosen as parents.

これは、witnessが新しいユニットを構成するとき、最近のユニットのみが親として選ばれる候補であることを意味します。

We might expect, therefore, that all future current MCs will converge no farther (when traveling back in time) than a particular stability point.

したがって、将来の現在のすべてのMCが特定の安定点よりも遠くに収束することはありません（時間を遡って移動する場合）。

Indeed, the genesis unit is a natural initial stability point.

確かに、ジェネシスユニットは自然の初期安定点です。

Assume we have built a current MC based on the current set of childless units, and there was some point on this MC that was previously believed to be stable, i.e. all future current MCs are believed to converge on or before this point (again, when traveling back in time), and then travel along the same route.

私たちが子なしユニットの現在のセットに基づいて現在のMCを構築し、以前は安定していると考えられていたこのMC上の点がいくつかあったとします。すなわち、すべての将来の現在のMCは、この時点（または、時間的に戻るとき）に、またはその前に収束し、次いで、同じ経路に沿って移動すると考えられる。

If we can find a way of advancing this point forward (away from the genesis), we can prove by induction that a stability point exists.

この点を前進させる方法（起源から離れて）を見つけることができれば、安定点が存在することを誘導で証明することができます。

Note that if we forget about all parents except the best parent, our DAG will be reduced to a tree that consists only of best parent links.

最良の親を除くすべての親を忘れた場合、DAGは最良の親リンクのみからなるツリーに縮小されます。

Obviously, all MCs will go along the branches of this tree.

明らかに、すべてのMCはこのツリーの枝に沿って行きます。

We then need to consider two cases – when the tree does branch in the current stability point and when it does not – and decide if we can advance the stability point to the next MCI.

次に、ツリーが現在の安定点で分岐していない場合とそうでない場合の2つのケースを検討し、安定点を次のMCIに進めることができるかどうかを判断する必要があります。

Figure 5. A tree composed of best-parent links.
All but one branches stop growing after some point.

図5.最良の親リンクからなるツリー。
1つの支店を除くすべての支店は、ある時点後には成長を止める。

First, assume the tree does not branch.

まず、ツリーが分岐しないと仮定します。

We then need to consider the possibility that a new branch will still be added and somehow supported by the witnesses so that it outgrows the existing branch.

新しい支店がまだ追加され、witnessが何らかの形で支えられ、既存の支店を上回る可能性を考慮する必要があります。

The other possibility is that the witnesses put so much weight in support of the existing branch, that the requirement of including one’s previous unit leaves them no options but continue supporting the existing branch.

もう1つの可能性は、witnessが既存の支店の支援のために非常に重視していることである。

Let’s quantify the latter possibility.

後者の可能性を定量化しましょう。

Remember that best parent is selected as the parent with the greatest witnessed level.

最良の親は証明されたレベルが最も高い親として選択されていることを忘れないでください。

Let’s travel back in time along the current MC from the tip until we meet the majority of witnesses (we are referring to witnesses as defined by the unit lying on the current stability point).

私たちが大多数のwitnessに会うまで（現在の安定点にあるユニットによって定義された目撃者を参照しています）、現在のMCに沿って時間をかけて遡りましょう。

If at least one of them lies earlier than the current stability point, we do not try to advance the stability point, otherwise we proceed.

それらのうちの少なくとも1つが現在の安定点より前にある場合、安定点を前進させようとしません。

In this case, all these witnesses are already “invested” into the current MC.

この場合、これらのwitnessはすべて、すでに現在のMCに「投資」されています。

Among these witnesses, we find the minimum witnessed level min_wl.

これらのwitnessの中で、証明された最小レベル min_wl を見つける。

When any of these witnesses posts a new unit, this unit might have parents whose MC leads to the current MC and parents whose MC leads to a competing branch, and the parent with the highest witnessed level will be selected as best parent and will define the direction of the next current MC.

これらのwitnessのいずれかが新しいユニットを掲示すると、このユニットは、MCが現在のMCにつながる親とMCが競合する支店につながる親を有する可能性があり、証明されたレベルの最も高い親が最良の親として選択され、次の現在のMCの方向を定義する。

Since the witness has to include its previous unit, the witnessed level of the parent leading to the current MC will be at least min_wl.

witnessは以前のユニットを含める必要があるため、現在のMCにつながる親の証明されたレベルは少なくとも min_wl になります。

The witnessed level of any parent leading to the alternative branch will never exceed the level of the current stability point, even if all remaining (minority) witnesses flock to the alternative branch.

残っている（少数派の）witnessが別の支店に集まったとしても、別の支店につながる親の証明されたレベルは、現在の安定ポイントのレベルを決して超えません。

Therefore, if the current MC grows far enough so that min_wl is greater than the level of the current stability point, the majority of witnesses will have to increase support for the existing current MC, the alternative branch has then lost all chances to win, and we can move the stability point forward to the next MCI.

したがって、現在のMCが min_wl が現在の安定点のレベルよりも大きくなるように十分に大きくなると、witnessの大多数は既存の現在のMCのサポートを増やさなければならないでしょう。別の支店は勝つチャンスをすべて失いました。安定点を次のMCIに移動することができます。

Next, assume the tree does branch.

次に、ツリーが分岐すると仮定します。

We need to find a condition where the alternative branches will lose any chance to outgrow the current MC.

私たちは、別の支店が現在のMCを超える可能性を失うという条件を見つける必要があります。

Let’s start by defining min_wl as in the previous case.

前の例のように min_wl を定義することから始めましょう。

Among all units on the alternative branches, we then select those that increase the witness level, i.e. their own witnessed level is greater than that of every parent.

別の支店上のすべてのユニットの中で、証明されたレベルを上げるユニット、つまり証明されたレベルがすべての親のレベルよりも大きいものを選択します。

Among these, we find the maximum level.

これらの中で、我々は最大レベルを見つける。

Then, even if all the remaining (minority) witnesses gather on the alternative branches, the witnessed level on the alternative branches will never exceed this maximum level.

残りの（少数の）witnessのすべてが別の支店に集まっても、別の支店の証明されたレベルは決してこの最大レベルを超えません。

Therefore, if this maximum level is less than min_wl, game is over for the alternative branches, and we can advance the stability point along the current MC.

したがって、この最大レベルが min_wl より小さい場合、別の支店のゲームは終了し、現在のMCに沿って安定点を進めることができます。

Thus, there is a point on the current MC before which the MC will never change (assuming the majority of witnesses don’t post nonserial units).

したがって、現在のMC上にMCが決して変更されない点がある（witnessの大多数が非直列ユニットを掲示しないと仮定して）。

The total order defined relative to this MC is therefore also final.

したがって、このMCに関連して定義される全体の順序も最終的です。

If we had nonserials, our decision about which one of them is valid, is final as well.

私たちが非直列を持っていれば、どちらが有効かどうかの決定も最終的なものです。

If a new nonserial ever appears that conflicts with anything already on the stable MC, the new nonserial unit will definitely be ordered after the old counterpart, and the new one will be deemed invalid.

安定したMC上のものと既に衝突している新しい非直列が現れた場合、新しい非直列ユニットは古いカウンターパートの後に注文され、新しいものは間違いなく無効とみなされます。

Therefore, any payment made in the unit included on the stable MC is already irreversible.

したがって、安定したMCに含まれるユニットで行われた支払いは、すでに元に戻すことができません。

Unlike Bitcoin where transaction finality is only probabilistic, this is deterministic transaction finality.

トランザクションの最終性が唯一確率的であるBitcoinとは異なり、これは決定的なトランザクションの最終性です。

Every user builds his own (subjective) current MC based on the units that he sees.

すべてのユーザは、自分が見ているユニットに基づいて、自分の（主観的な）現在のMCを構築します。

Since the propagation of new units is not instant, and they may arrive in different order to different users, the users will have different current MCs and different opinions about the last stable point of the MC at any given time.

新しいユニットの普及は瞬時ではなく、異なるユーザに異なる順序で到着する可能性があるので、ユーザはいつでもMCの最後の安定点に関する異なる現在のMCおよび異なる意見を有する。

However, since the current MC is defined solely by the set of units known to the user, in case user B hasn’t yet advanced his stability point to the same MCI as user A, he will inevitably do that later – i.e. as soon as he receives the same units as user A, or more.

しかし、現在のMCは、ユーザに知られているユニットのセットによってのみ定義されるので、ユーザBがユーザAと同じMCIに安定点をまだ進めていない場合、必然的に後で彼はユーザA以上のユニットを受け取ります。

Thus the opinions of different users about the state of any given unit are eventually consistent.

したがって、任意のユニットの状態に関する異なるユーザの意見は、最終的に一貫している。

8.Storage of nonserial units

8.非直列単位の保管

When we decide that a unit is a nonserial, we still have to store it.
ユニットが非セリアルであると判断した場合でも、それを保存する必要があります。

However, part of its data is replaced with a hash of the data. This rule serves two purposes.
ただし、そのデータの一部はデータのハッシュに置き換えられます。このルールは2つの目的を果たします。

First, to reduce storage consumed by a unit that nobody paid for (the entire content of the nonserial unit is deemed invalid, including its payment of commissions).
第一に、誰も支払っていないユニット（非シリアルユニットの全コンテンツは、コミッションの支払いを含む、無効とみなされる）によって消費されるストレージを削減すること。

Second, to reduce the utility of the nonserial to the user who sent it, because the hash replaces all useful data that the author wanted to store (for free).
第2に、ハッシュは著者が（自由に）保存したいと思ったすべての有用なデータを置き換えるため、非シリアルのユーティリティをそれを送信したユーザに還元するためです。

This prevents attackers from abusing nonserials as a way to store large amounts of data for free.
これにより、攻撃者が大量のデータを無料で保存する方法として、非シリアルを悪用することを防ぎます。

The hash that is stored instead of the full content still has some utility to the attacker, as he can store the original data himself and use the hash to prove that the data existed.
完全なコンテンツの代わりに格納されているハッシュは、元のデータを自分自身で保存し、そのデータが存在することを証明するためにハッシュを使用することができるため、攻撃者には何らかのユーティリティーを持っています。

But remember that:
しかし、

1. He still has to pay for one unit that is deemed valid
2. If the attacker is already internally storing metadata that is necessary to interpret Byteball data, he could do equally well by just combining all his data into a Merkle tree and using Byteball to store only its Merkle root for the cost of one small unit.

1.彼はまだ妥当とみなされる1つのユニットに支払う必要がある
2.攻撃者が既にByteballデータを解釈するために必要なメタデータを内部に格納している場合、彼はすべてのデータをMerkleツリーに結合し、Byteballを使用して1つの小さなユニットのコストでMerkleルートのみを保存するだけです。

Under this design, there is therefore no self-interest in trying to send nonserials.
したがって、この設計では、非シリアルを送信しようとすることに自己利益はない。

It ought to be mentioned that we cannot just reject nonserials the first time we see them.
私たちが最初に見たときに非直列を拒否することはできないと言わざるを得ない。

If we did, an attacker could send his nonserials to different users in different order.
もしそうしたならば、攻撃者は自分のノンシリアスを異なるユーザーに異なる順序で送ることができます。

Different users would then stick to the versions they first received and reject everything based on the other version, so the attacker would succeed in partitioning the network.
異なるユーザーは、最初に受け取ったバージョンに固執し、他のバージョンに基づいてすべてを拒否するため、攻撃者はネットワークを分割することに成功します。

That’s why we have to store both versions and then decide on their order.
だから我々は両方のバージョンを保存してから注文を決める必要があります。

Even more, users should forward nonserials to peers just like any other units, as the sooner peers learn about the nonserials the better.
さらに、他のユニットと同様に、非シリアルをピアに転送する必要があります。

We still try to avoid including nonserials if possible: the parent selection algorithm excludes nonserials as long as they are childless.
可能であれば、非直列を含むことを避けるよう努力しています。親選択アルゴリズムは、非直列である限り非直列を除外します。

For this reason, it’s desirable to help peers learn about nonserials as soon as possible.
このため、できるだけ早く非セリアルについて学ぶのを助けることが望ましいです。

9. Balls

1. ボール

After a unit becomes stable (i.e. it is included on the stable part of the MC) we create a new structure based on this unit, we call it a ball:
ユニットが安定すると（すなわち、それがMCの安定した部分に含まれる）、このユニットに基づいて新しい構造を作り、それをボールと呼ぶ。

ball: {
    unit: "hash of unit",
    parent_balls: [array of hashes of balls based on parent units],
    is_nonserial: true, // this field included only if the unit is
    nonserial
    skiplist_balls: [array of earlier balls used to build skiplist]
}

Every ball includes information about all its ancestor balls (via parents), hence the amount of information it depends on grows like snowball.
すべてのボールには（親を介して）すべての祖先ボールに関する情報が含まれているため、依存する情報の量はスノーボールのように大きくなります。

We also have a flag in the ball that tells us if it ended up being invalid (nonserial), and we have references to older balls that we’ll use later to build proofs for light clients.
私たちはまたボールが無効であるかどうかを知らせるフラグを持っています。そして、軽いクライアントの証拠を作成するために後で使用する古いボールを参照しています。

We can only build a ball when the corresponding unit becomes stable and we know for certain whether it is serial.
対応するユニットが安定したときだけボールを作ることができ、シリアルであるかどうかは確かにわかります。

Since the current MCs as viewed by different users are eventually consistent, they will all build exactly the same ball based on the same unit.
異なるユーザーから見た現在のMCは最終的に一貫しているので、同じユニットに基づいてまったく同じボールを構築します。

10. Last ball

1. 最後のボール

To protect the balls (most importantly, the is_nonserial flag) from modification, we require each new unit to include a hash of the last ball that the author knows about(which is the ball built from the last stable unit, and it lies on the MC).
ボール（最も重要なのは、is_nonserialフラグ）を変更から保護するために、新しいユニットには最後の安定したユニットから構築されたボールである最後のボールのハッシュを含める必要があります。 MC）。

This way, the last ball will be protected by the author’s signature. Later on, the new unit itself will be (directly or indirectly) included by witnesses.
この方法で、最後のボールは作者の署名によって保護されます。その後、新しいユニット自体が証人によって（直接的または間接的に）含まれることになります。

If someone who doesn’t have the entire Byteball database wants to know if a particular unit is serial, he would give us a list of witnesses he trusts to behave honestly, and we would build a chain of recent units that includes the majority of the said witnesses, then read last ball from the oldest unit of the chain, and use balls to build a hash tree that has the last ball at the top and includes the requested unit somewhere below.
Byteballデータベース全体を持っていない人が、特定のユニットが連続しているかどうかを知りたければ、彼は信頼する証人のリストを正直に行動させるでしょう。証人は、チェインの最古のユニットから最後のボールを読んで、ボールを使って、最後のボールが上にあり、下のどこかに要求されたユニットを含むハッシュツリーを構築する。

This hash tree is similar to a very tall Merkle tree, with additional data fed in at each node.
このハッシュツリーは非常に背の高いMerkleツリーに似ていて、各ノードで追加のデータが入力されます。

The tree can be optimized using the skiplist.
ツリーはskiplistを使用して最適化することができます。

The reference to the last ball also lets users see what their peers think about the stability point of the MC and compare it with their own vision.
また、最後のボールを参照することで、ユーザーはMCの安定点について相手がどのように考えているのかを見て、自分のビジョンと比較することができます。

We also require that the last ball lies no sooner than last ball of every parent.
また、最後のボールは、すべての親の最後のボールより遅くなくてはなりません。

This ensures that the last ball either advances forward along the MC or stays in the same position, but never retreats.
これにより、最後のボールがMCに沿って前進するか、同じ位置にとどまるが、後退することはない。

To further reduce the degrees of freedom of adversaries, we add one more requirement: a unit’s witness list must be compatible with that of each unit that lies on the trailing part of the unit’s MC between this unit and the last ball’s unit.
敵の自由度をさらに減らすために、もう1つの要件が追加されます。ユニットの目撃者リストは、ユニットと最後のボールのユニットの間のユニットのMCの後部にある各ユニットの目録と互換性がなければなりません。

This requirement ensures that all changes to the witness list first reach stability point before trying another change.
この要件は、別の変更を試みる前に、監視リストへのすべての変更が最初に安定点に達することを保証します。

Otherwise, an attacker might inject a significantly modified witness list onto the MC and stop posting from the addresses of the new witnesses.
それ以外の場合、攻撃者は大幅に変更された証人リストをMCに注入し、新しい証人のアドレスからの投稿を停止する可能性があります。

In such instances, the stability point would not be able to advance past the stretch occupied by the attacker’s witnesses.
このような場合、安定地点は攻撃者の目撃者が占めるストレッチを超えて前進することはできません。

The requirement that witness lists of all contemporary units are mostly similar means that all users have mostly similar views about who can be trusted to serve as lighthouses for the community at the current time.
現代のすべてのユニットの目録リストがほぼ類似しているという要件は、現時点でコミュニティの灯台として誰が信頼できるかについて、すべてのユーザーがほぼ同じ意見を持っていることを意味します。

This is similar to biology, where organisms of the same species have to have mostly the same genes.
これは同じ種の生物がほとんど同じ遺伝子を持たなければならない生物学に似ています。

Small variance of the witness list allows for evolutionary change that still preserves the integrity of the system.
目撃者リストの小さな差異は、システムの完全性を維持する進化的変化を可能にする。

11. Witness list unit

1. 目撃者リストユニット

It is expected that many users will want to use exactly the same witness list.
多くのユーザーがまったく同じ監視リストを使用したいと考えられます。

In this case, to save space, they don’t list the addresses of all 12 witnesses. Rather, they give a reference to another earlier unit, which listed these witnesses explicitly.
この場合、スペースを節約するために、12人のすべての証人の住所は記載されていません。むしろ、彼らはこれらの目撃者を明示的に列挙した別の初期のユニットへの参照を与える。

The witness list unit must be stable from the point of view of the referencing unit, i.e. it must be included into the last ball unit.
目撃者リストユニットは、参照ユニットの観点から安定でなければならず、すなわち、それは最後のボールユニットに含まれなければならない。

12. Unit structure

1. ユニット構造 これはユニットの例です：

{
    version: '1.0',
    alt: '1',
    messages: [ {
        app: 'payment',
        payload_location: 'inline',
        payload_hash:
        'AegecfpDzh8xvdyIABdynrcP6CTd4Pt42gvRiv0Ftjg=',
        payload: {
            inputs: [{
                unit:
                '7yctnKyuAk5P+mFgFQDdDLza88nkceXYjsTs4e3doQA=',
                message_index: 0,
                output_index: 1
            } ],
            outputs: [
                { address: 'DJ6LV5GPCLMGRW7ZB55IVGJRPDJPOQU6',
                amount: 208 },
                { address: 'Z36JFFX2AH7X5JQ2V2C6AQUUOWFESKZ2',
                amount: 3505 }
            ]
        }
    } ],
    authors: [ {
        address: 'DJ6LV5GPCLMGRW7ZB55IVGJRPDJPOQU6',
        authentifiers: {
            r:
            '3eQPIFiPVLRwBwEzxUR5thqn+zlFfLXUrzAmgemAqOk35UvDpa4h
            79Fd6TbPbGfb8VMiJzqdNGHCKyAjl786mw=='
        }
    } ],
    parent_units: [
        'B63mnJ4yNNAE+6J+L6AhQ3EY7EO1Lj7QmAM9PS8X0pg=',
        'D6O1/D9L8vCMhv+8f70JecF93UoLKDp3e2+b92Yh2mI=',
        'ZxqzWP6q6hDNF50Wax8HUK212lH/KSIRdW5a6T9h3DM='
    ],
    last_ball: '8S2ya9lULt5abF1Z4lIJ4x5zYY9MtEALCl+jPDLsnsw=',
    last_ball_unit: 'bhdxFqVUut6V3N2D6Tyt+/YD6X0W+QnC95dMcJJWdtw=',
    witness_list_unit:
    'f252ZI2MN3xu8wFJ+LktVDGsay2Udzi/AUauE9ZaifY='
}

Here:
ここに:

• version is the protocol version number. The unit will be interpreted according to this version of the protocol;
• alt is an identifier of alternative currency, we’ll discuss this later;
• messages is an array of one or more messages that contain actual data;
  • app is the type of message, e.g. ‘payment’ for payments, ‘text’ for arbitrary text messages, etc;
  • payload_location says where to find the message payload. It can be ‘inline’ if the payload is included in the message, ‘uri’ if the payload is available at an internet address, ‘none’ if the payload is not published at all, is stored and/or shared privately, and payload_hash serves to prove it existed at a specific time;
  • payload_hash is a hash of the payload in base64 encoding;
  • payload is the actual payload (since it is ‘inline’ in this example). The payload structure is app-specific. Payments are described as follows:
    • inputs is an array of input coins consumed by the payment. All owners of the input coins must be among the signers (authors) of the unit;
      • unit is hash of the unit where the coin was produced. To be spendable, the unit must be included in last_ball_unit;
      • message_index is an index into the messages array of the input unit. It indicates the message where the coin was produced;
      • output_index is an index into the outputs array of the message_index’th message of the input unit. It indicates the output where the coin was produced;
    • outputs is an array of outputs that say who receives the money;
      • address is the Byteball address of the recipient;
      • amount is the amount he receives;
• authors is an array of the authors who created and signed this unit. All input coins must belong to the authors;
  • address is the author’s Byteball address;
  • authentifiers is a data structure that proves the author’s authenticity. Most commonly these are ECDSA signatures;
• parent_units is an array of hashes of parent units. It must be sorted alphabetically;
• last_ball and last_ball_unit are hashes of last ball and its unit, respectively;

• witness_list_unit is hash of the unit where one can find the witness list.

• versionはプロトコルのバージョン番号です。ユニットは、このバージョンのプロトコルに従って解釈されます。

• altは代替通貨の識別子です。これについては後で説明します。

• messagesは、実際のデータを含む1つ以上のメッセージの配列です。

  • appはメッセージのタイプです。支払いのための「支払い」、任意のテキストメッセージのための「テキスト」など。
  • payload_locationは、メッセージのペイロードを見つける場所を示します。ペイロードがメッセージに含まれている場合は「インライン」、インターネットアドレスでペイロードが利用できる場合は「uri」、ペイロードがまったく公開されていない場合は「none」、プライベートに格納され、共有されたり、payload_hashそれが特定の時間に存在したことを証明する役割を果たします。
  • payload_hashは、base64エンコーディングでのペイロードのハッシュです。
  • ペイロードは実際のペイロードです（この例では「インライン」なので）。ペイロード構造はアプリ固有です。支払いは以下のように記述されます：
    • inputsは、支払いで消費された入力コインの配列です。入力コインのすべての所有者は、ユニットの署名者（著者）の間でなければなりません。
      • ユニットはコインが生産されたユニットのハッシュです。費やせるようにするには、ユニットをlast_ball_unitに含める必要があります。
      • message_indexは、入力ユニットのmessages配列へのインデックスです。それは、コインが生産された場所のメッセージを示します。
      • output_indexは、入力ユニットのmessage_index番目のメッセージのoutputs配列へのインデックスです。コインが生産された場所を示します。
    • outputsは、誰がお金を受け取るかを示す出力の配列です。
      • addressは、受信者のByteballアドレスです。
      • 金額は受け取った金額です。

• 著者は、このユニットを作成して署名した著者の配列です。すべての投入コインは、著者に属していなければなりません。

  • アドレスは著者のByteballアドレスです。
  • 認証者は、著者の真正性を証明するデータ構造です。最も一般的には、ECDSA署名です。

• parent_unitsは親ユニットのハッシュの配列です。アルファベット順にソートする必要があります。

• last_ballとlast_ball_unitはそれぞれ最後のボールとそのユニットのハッシュです。

• witness_list_unitは、監視リストを見つけることができるユニットのハッシュです。

All hashes are in base64 encoding.
すべてのハッシュは、ベース64エンコーディングです。

Note that there is no timestamp field in the unit structure.
ユニット構造にタイムスタンプフィールドがないことに注意してください。

In Byteball, there are no protocol rules that rely on clock time.
Byteballでは、クロック時間に依存するプロトコルルールはありません。

it’s simply not needed, as it is enough to rely on the order of events alone.
単にイベントの順序だけに頼るだけで十分です。

Timestamp is still added to units when they are forwarded from node to node.
タイムスタンプは、ノードからノードに転送されるときに、ユニットに追加されます。

However, this is only advisory and used by light clients to show in wallets the approximate time when a unit was produced, which may significantly differ from the time it was received as light clients may go offline for extended periods of time.
しかし、これは唯一の勧告であり、軽量クライアントが長い時間オフラインになる可能性があるため、ユニットが製造されたときのおおよその時間を財布に表示するためにライトクライアントによって使用されます。

13. Commissions

1. 手数料

As mentioned before, the cost to store a unit is its size in bytes.
前述したように、ユニットを格納するコストはバイト単位のサイズです。

The commission issplit into two parts: headers commission and payload commission.
手数料は、ヘッダー手数料と手数料手数料の2つの部分に分割されます。

Payload commission is equal to the size of messages; headers commission is the size of everything else.
ペイロードコミッションはメッセージのサイズに等しい。ヘッダー手数料は他のすべてのサイズです。

The two types of commissions are distributed differently.
2種類の手数料は、異なる方法で分配されます。

Headers commission goes to one of the future units which takes the payer unit as parent.
ヘッダー手数料は、支払人単位を親として取る将来の単位の1つに移ります。

The receiver is selected only after both the payer unit’s MCI and the next MCI become stable.
受信者は、支払人単位のMCIと次のMCIの両方が安定した後にのみ選択されます。

To determine the receiver, we take those children whose MCI is equal to or 1 more than the MCI of the payer.
受信者を決定するために、私たちはMCIが支払人のMCI以上である子どもを服用します。

The hashes of each of these children are concatenated with the hash of the unit lying on the next MCI (relative to the payer), and the child with the smallest hash value (in hex) wins the headers commission.
これらの子それぞれのハッシュは、次のMCI（支払人に対して）にあるユニットのハッシュと連結され、最小のハッシュ値（16進数）を持つ子がヘッダ手数料を獲得する。

This hashing with the next MC unit is designed to introduce unpredictability (the next MC unit is not known beforehand) and render useless any attempts to improve one’s chances of receiving commission by playing with one’s own unit hash.
次のMCユニットとのこのハッシングは、予期せぬことを招くように設計されており（次のMCユニットは事前に知られていません）、自分自身のユニットハッシュで遊ぶことによって手数料を受け取る可能性を高める試みは役に立たなくなります。

At the same time, restricting candidates to those whose MCI is no more than 1 greater than the MCI of the payer, incentivizes the selection of the most recent units as parents.
同時に、MCIが支払人のMCIより1を超えないものに候補者を限定し、最新のユニットの選択を親としてインセンティブにする。

This is useful to keep the DAG as narrow as possible.
これは、DAGを可能な限り狭くするために役立ちます。

We pay only the headers commission and not the entire commission to those who are quick to pick our unit as parent, for the following reason.
以下の理由から、私たちは親権者として私たちのユニットを選ぶのが速い人に委託手数料だけを支払うのではなく、委託手数料全体を支払うわけではありません。

If we did pay the entire commission, we would have incentivized abusive behavior: split one’s data into several chunks and build a long chain of one’s own units storing one chunk per unit.
手数料全体を支払った場合は、データを複数のチャンクに分割し、ユニットごとに1つのチャンクを格納する独自のユニットの長鎖を構築するという虐待的な行動をインセンティブにしていました。

All the commissions paid in a previous unit would then be immediately collected by the same user in the next unit.
前のユニットで支払われたすべての手数料は、次のユニットの同じユーザによってすぐに回収されます。

As we pay only the headers commission, such behavior is not profitable because to produce each additional element of the chain one has to spend additional headers commission – roughly the same as one earns.
ヘッダー手数料のみを支払うので、チェーンの各追加要素を生成するためには、追加のヘッダー手数料を費やさなければならないので、そのような振る舞いは有益ではありません。

We use the remaining (payload) commission to incentivize others whose activity is important for keeping the network healthy.
残りの（手数料）手数料を使用して、ネットワークを健全に保つために重要な活動を行っている人たちにインセンティブを与えます。

Payload commission goes to witnesses.
有償手数料は証人に送られます。

To incentivize witnesses to post frequently enough, we split payload commission equally among all witnesses who are quick enough to post within 100 MC indexes after the paying unit (the faster they post, the faster this unit becomes stable).
目撃者に十分に頻繁にポストするようインセンティブを与えるため、paying unitの後に100 MC index以内に投稿するのに十分な速さのすべての目撃者にpayload commissionを均等に分割します（速くポストするほど速くなります）。

If all 12 witnesses have posted within this interval, each receives 1/12 of the payload commission.
12人の証人のすべてがこの期間内に投稿した場合、それぞれのペイロードコミッションの1/12を受け取る。

If only one witness has posted, he receives the entire payload commission.
証人が1人しか投稿されていない場合、彼はペイロードコミッション全体を受け取る。

In the special case that no witness has posted within this interval, they all receive 1/12 of payload commission.
この期間内に証人が掲載されない特別なケースでは、彼らはすべてペイロードコミッションの1/12を受け取る。

If the division produces a fractional number, it is rounded according to mathematical rules.
部門が小数を生成する場合は、数学的ルールに従って四捨五入されます。

Because of this rounding, the total commission paid out to witnesses may not be equal to the total payload commission received from the unit’s author(s), so the total money supply will change slightly as well.
この丸めのため、証人に支払われた総手数料は、その作者の手数料手数料と同じではない可能性があります。

Obviously, the distribution happens only after MCI+100 becomes stable, where MCI is the MCI of the paying unit.
明らかに、分配はMCI + 100が安定した後にのみ起こり、MCIは支払い単位のMCIである。

To spend the earned headers commissions or witnessing commissions, the following input is used:
獲得したヘッダー手数料や目撃手数料を費やすために、以下の入力が使用されます：

inputs: [
    {
        type: "headers_commission",
        from_main_chain_index: 123,
        to_main_chain_index: 196
    },
    {
        type: "witnessing",
        from_main_chain_index: 60,
        to_main_chain_index: 142
    },
    …
]

Such inputs sweep all headers or witnessing commissions earned by the author from commission paying units that were issued between main chain indexes from_main_chain_index and to_main_chain_index.
このような入力は、メインチェーンインデックスfrom_main_chain_indexとto_main_chain_indexの間で発行されたコミッション支払単位から、著者が獲得したすべてのヘッダーまたは目撃手数料を掃引します。

Naturally, to_main_chain_index must be stable.
もちろん、to_main_chain_indexは安定していなければなりません。

When a unit signed by more than one author earns headers commission, there is so far ambiguity as to how the commission is split among the authors.
複数の著者によって署名されたユニットがヘッダ手数料を得るとき、手数料が著者の間でどのように分割されるかについて、あまりにもあいまいさがある。

To remove the ambiguity, each unit that is signed by more than one author must include a data structure that describes the proportions of revenue sharing:
あいまいさを取り除くには、複数の著者によって署名された各ユニットに、収益分配の比率を記述するデータ構造を含める必要があります。

unit: {
    …
    earned_headers_commission_recipients: [
        {address: "ADDRESS1", earned_headers_commission_share: 30},
        {address: "ADDRESS2", earned_headers_commission_share: 70}
    ],
    …
}

The addresses who receive the commissions needn’t be the same as the author addresses – the commission can be sent to any address.
手数料を受け取る住所は、著者の住所と同じである必要はなく、手数料はどの住所にでも送ることができます。

Even if the unit is signed by a single author, it can include this field to redirect headers commissions elsewhere.
ユニットが単一の著者によって署名されていても、このフィールドを組み込むことで、他の手数料のヘッダをリダイレクトすることができます。

14. Confirmation time

1. 確認時刻

Confirmation time is the time from a unit entering the database to reaching stability.
確認時間は、データベースに入るユニットから安定性に達するまでの時間です。

It depends on how often the witnesses post, since to reach stability we need to accumulate enough witness-authored units on the MC after the newly added unit.
それは、証人が投稿する頻度に依存します。なぜなら、安定性に達するためには、新たに追加されたユニットの後に証人作成の単位を十分に蓄積する必要があるからです。

To minimize the confirmation period, the witnesses should post frequently enough (which they are already incentivized to do via commission distribution rules) but not too frequently.
確認期間を最小限に抑えるために、証人は十分に頻繁に投稿しなければなりません（すでにコミッション配当ルールを介して行うことを奨励していますが）。

If two or more witnesses issue their units nearly simultaneously (faster than it typically takes to propagate a new unit to other witnesses), this may cause unnecessary branching of the tree composed of best-parent links, which would delay stability.
2人以上の目撃者がユニットをほぼ同時に発行した場合（通常は新しいユニットを他の目撃者に伝播するよりも速く）、これにより最善の親リンクからなるツリーの不要な分岐が発生し、安定性が遅くなります。

For this reason, the best confirmation times are reached when the witnesses are well connected and run on fast machines so that they are able to quickly validate new units.
このため、証人が接続されて高速マシンで実行され、新しいユニットを素早く検証できるようになると、最高の確認時間に達することができます。

We estimate the best confirmation times to be around 30 seconds; this is only reachable if the flow of new units is large enough so that the witnesses earn more from witnessing commissions than they spend for posting their own units.
最も良い確認時間は約30秒と推定されます。これは、新しいユニットの流れが十分に大きくて、目撃者が自分のユニットを掲示するために費やすよりも多くの報酬を手数料から得ることができる場合にのみ到達可能です。

Despite the period of full confirmation being rather long, a node that trusts its peers to deliver all new units without filtering may be reasonably sure that once a unit was included by at least one witness, plus a typical latency has elapsed (the time it takes a new unit to travel from peer to peer), the unit will most likely reach finality and be deemed valid.
完全確認の時間がかなり長いにもかかわらず、フィルタリングせずにすべての新しいユニットを配信することを同輩に信頼するノードは、ユニットが少なくとも1人の証人によって含まれ、さらに典型的な待ち時間が経過したことを合理的に確かめることができますピアツーピアから移動する新しいユニット）、ユニットは最終的に到達し、有効であるとみなされます。

Even if a double-spend appears later, it will be likely ordered after this unit.
後で二重支出が表示されても、このユニットの後に注文される可能性が高くなります。

15. Partitioning risk

1. パーティショニングのリスク

The network of Byteball nodes can never be partitioned into two parts that would both continue operating without noticing.
Byteballノードのネットワークは決して2つの部分に分割することはできません。

Even in the event of a global network disruption such as a sub-Atlantic rat cutting the cable that connects Europe and America, at least one of the sides of the split will notice that it has lost the majority of witnesses, meaning that it can’t advance the stability point, and nobody can spend outputs stuck in the unstable part of the MC. Even if someone tries to send a double-spend, it will remain unstable (and therefore unrecognized) until the connection is restored.
ヨーロッパとアメリカを結ぶケーブルを切断する亜大西洋ラットのような世界的なネットワークの混乱の場合でも、スプリットの少なくとも1つの側はそれが大多数の証人を失ったことに気付くでしょう。つまり、安定点を前進させ、誰もMCの不安定な部分に詰まった出力を費やすことはできません。誰かが二重支出を送ろうとしても、接続が回復するまでは不安定な状態（したがって認識されない状態）のままです

The other part of the split where the majority of witnesses happens to be, will continue as normal.
目撃者の大部分が起こっている分割の他の部分は、通常通り続きます。

16. Censorship

1. 検閲

By design, it is already impossible to modify or erase any past records in Byteball.
設計上、Byteballの過去の記録を変更または消去することは既に不可能です。

It is also quite hard to stop any particular types of data from entering the database.
特定のタイプのデータがデータベースに入るのを止めることも非常に困難です。

First, the data itself can be concealed and only its hash be actually posted to the database to prove that the data existed.
まず、データそのものを隠すことができ、そのハッシュのみがデータベースに実際にポストされ、データが存在することを証明します。

The data may only be revealed after the hash is stored and its unit has been included by other units so that it has become unrevisable.
データは、ハッシュが格納され、そのユニットが他のユニットによって包含された後にしか公開されないので、復元不可能になっている可能性があります。

Second, even when the data is open, the decision to include or not include it in the database is delegated to numerous anonymous users who might (and in fact are incentivized to) take the new unit as a parent.
第二に、たとえデータが公開されていても、それをデータベースに含めるか否かの決定は、新しいユニットを親として扱う（そして実際にインセンティブを与える）多くの匿名ユーザに委任される。

Someone who tries to censor undesirable units will have to not only avoid including them directly (as parents) but also indirectly, through other units.
(This is different from Bitcoin where miners or mining pools can, and do, filter individual transactions directly. Besides, Bitcoin users have no say in who is to become a miner.)
望ましくないユニットを検閲しようとする人は、それらを直接（親として）含むのではなく、間接的に他のユニットを通す必要があります。
（これは、鉱業者や採掘プールが個々の取引を直接フィルタリングすることができるBitcoinとは異なります。また、Bitcoinユーザーは、誰が鉱山者になるのかについての発言はありません）。

As the number of units which include the “offending” unit snowballs, any attempt to avoid it would entail censoring oneself.
「怒っている」単位の雪玉を含むユニットの数として、それを避ける試みは自分自身を検閲することを必要とする。

Only the majority of witnesses can effectively impose forbidden content rules – if users choose such witnesses.
目撃者の大部分のみが、禁止されたコンテンツルールを効果的に課すことができます。

17. Choosing witnesses

1. 目撃者の選択

Reliance on witnesses is what makes Byteball rooted in the real world. At the same time, it makes it highly dependent on human decisions.
目撃者への信頼は、Byteballを現実の世界に根ざしたものにしています。同時に、人間の意思決定に大きく依存します。

The health of the system depends on users responsibly setting the lists of witnesses they do trust.
システムの健全性は、信頼できる目撃者のリストを責任を持って設定するユーザーに依存します。

This process cannot be safely automated, for example if most users start autoupdating their witness lists to match the lists of most recently observed units, just to be compatible, this can be easily exploited by an attacker who floods the network with his own units that gradually change the predominant witness list to something of the attacker’s choosing.
このプロセスは安全に自動化することはできません。たとえば、ほとんどのユーザーが直近の監視対象ユニットのリストに一致するように監視リストの自動更新を開始し、互換性がある場合、これは徐々に自分のユニットでネットワークを氾濫させる攻撃者主な目撃者リストを攻撃者が選択したものに変更します。

While the maximalist recommendation could be “only edit witness lists manually”, which is too burdensome for most users, a more practical approach to witness list management is tracking and somehow averaging the witness lists of a few “captains of industry” who either have interest in caring for the network health or who have earned a good reputation in activities not necessarily connected with Byteball.
マキシマリスト勧告は、ほとんどのユーザーにとって負担が大きい「手動で監視リストを編集する」だけである可能性がありますが、目撃者リスト管理のより実践的なアプローチは、興味を持っている少数の「船長」の証人リストを追跡し、ネットワークの健康を守ること、またはByteballと必ずしも連携していない活動で良い評判を得ている人。

Some of them may be acting witnesses themselves.
彼らの中には証人として働く者もいるかもしれません。

Unlike witness lists, the lists of captains of industry don’t have to be compatible, and failing to update the list frequently enough doesn’t have any immediate negative implications such as being unable to find compatible parents and post a new unit.
目撃者リストとは異なり、業界のキャプテンのリストは互換性がなくてもよく、頻繁にリストを更新しないと、互換性のある親を見つけられず、新しいユニットを投稿するなど、すぐに否定的な意味を持ちません。

We expect that most users will use one of a relatively small number of most popular wallets, and such wallets will be set up by default to follow the witness list of the wallet vendor, who in turn likely watches the witness lists of other prominent players.
ほとんどのユーザーは、比較的少数の最も人気のある財布を使用することが予想され、そのような財布はデフォルトでウォレットベンダーの証人リストに準拠するように設定され、他の著名なプレイヤーの証人リストを監視する可能性があります。

Witnesses also have their witness lists, and it is recommended that users elect those witnesses who they trust to keep their witness lists representative of ordinary users’ beliefs.
目撃者には証人リストもあり、証人リストを通常のユーザーの信念の代表者とするために信頼する証人を選出することをお勧めします。

This is very important because no change to the predominant witness list can pass without approval of the majority of the current witnesses.
現在の目撃者の過半数の承認を得ずに優勢な目撃者リストに変更を加えることができないため、これは非常に重要です。

It is recommended that witnesses and would-be witnesses publicly declare their witness list policy (such as following and averaging witness lists of other reputable users), and that users evaluate their fitness for the job based on this policy, among other factors.
目撃者と証言者は証人リストのポリシーを公表し（他の評判の高いユーザーの証人リストを追跡し、平均化するなど）、このポリシーに基づいて、他の要素の中でもユーザーが仕事の適性を評価することが推奨されます。

Any breach of the declared policy will be immediately visible and will likely trigger a witness replacement campaign.
宣言されたポリシーの違反はすぐに目に見え、証人交換キャンペーンを引き起こす可能性があります。

The same is true for an unjustified amendment to the policy.
政策の不当な改正についても同様です。

The policy binds the witness and makes him follow public opinion, even when it turns against the witness himself or his friends.
この方針は証人に拘束され、証人自身または彼の友人に逆らっても世論に従うようにします。

As mentioned before, our protocol rules require that:
1. best parent is selected only among parents whose witness list has no more than 1 mutation;
2. there should be no more than 1 mutation relative to the witness list of the last ball unit;
3. there should be no more than 1 mutation relative to the witness lists of all the unstable MC units up to the last ball unit;
4. the stability point advances only when the current witnesses (as defined in the current stability point) post enough units after the current stability point.
前に述べたように、私たちのプロトコルルールは以下を必要とします：
1.最良の親は、目撃者リストに突然変異が1つしかない親の中から選択される。
2.最後のボールユニットの目撃者リストに対して1つ以上の突然変異があってはならない。
3.最後のボールユニットまでのすべての不安定なMCユニットの目撃者リストに対して、1つ以上の突然変異が存在してはならない。
4.現在の安定点の後に十分な単位を置いている現在の目撃者（現在の安定点で定義されている）が存在する場合にのみ、安定点が進む。

These rules are designed to protect against malicious and accidental forks.
これらのルールは、悪意のあるフォークや偶発的なフォークから保護するように設計されています。

At the same time, they imply that any changes of the predominant witness list have to be gradual, and each step has to be approved by the majority of the current witnesses.
同時に、主な証人リストの変更は徐々に行われなければならず、各ステップは現在の目撃者の過半数が承認しなければならないということを暗示している。

A one-position change has to first reach stability and recognition of the majority of old witnesses before another change can be undertaken.
1つのポジションの変更は、最初の安定性と古い証人の大部分の認識に到達しなければ、別の変更を行うことはできません。

If the community decides abruptly that two witnesses need to be replaced immediately, then after one change makes its way onto the MC, the second change will be blocked by rule 3 above until the first change reaches stability.
2人の目撃者を直ちに交換する必要があるとコミュニティが急に判断した場合、MCへの変更が1回行われた後、最初の変更が安定するまで、上記のルール3で2回目の変更がブロックされます。

Despite all the recommendations above it is still possible that due to the negligence of industry leaders, such witnesses are elected who later form a cartel and collectively block all attempts to replace any one of them in an attempt to keep the profits they are earning from witnessing commissions.
上記のすべての勧告にもかかわらず、業界のリーダーの過失により、後にカルテルを形成し、目撃から得ている利益を維持しようと、いずれか1つを置き換えるすべての試みをブロックする証人が選出される手数料。

If they do behave this way, it will be evident to everybody because their witness lists will remain unchanged, while the witness lists of most other industry leaders will differ by one mutation (the maximum allowed to remain compatible).
彼らがこのように行動すれば、ほとんどの他の業界リーダーの目撃者リストは1つの変異（互換性を保つことが許されている最大）によって異なるが、証人リストは変わらないので、誰にとっても明らかである。

If the old witnesses do not give in despite such evident pressure, the only recourse of the pro-change users is a “revolution” – i.e. to start a new coin that inherits all the balances, user addresses, etc from the old coin at some point but starts with a new witness list and adds a special protocol rule to handle this incompatible change at the moment of the schism.
古い証人がそのような明白な圧力にもかかわらず引き渡されないならば、変化の遅いユーザーの唯一の頼りになるのは「革命」です。つまり、古いコインからすべての残高、ユーザーアドレスなどを継承する新しいコインを始める新しい目撃者リストから始まり、分裂の瞬間にこの互換性のない変化を処理する特別なプロトコルルールを追加します。

To distinguish from the old coin, they would then assign a new value to the ‘alt’ field (this what ‘alt’ is for) and use it in all units issued under the new coin.
古いコインと区別するために、彼らは 'alt'フィールドに新しい値を割り当てて（これは 'alt'のためのものです）、新しいコインの下で発行されたすべてのユニットでそれを使用します。

As a result, users will hold two coins (the old alt=”1”, and the new e.g. alt=”2”) and will be able to spend both independently.
その結果、ユーザーは2つのコイン（古いalt = "1"、新しいたとえばalt = "2"）を保持し、両方を独立して使用することができます。

If the split was justified, the old coin will probably be abandoned, but all the data accumulated prior to the schism will be available as normal in the new coin.
分割が正当化された場合、古いコインは放棄される可能性がありますが、分割前に蓄積されたすべてのデータは新しいコインで通常通り利用可能になります。

Since the protocol is almost identical (except for the rule that handles the schism and the change of alt), it will be easy to update software installed on all user and merchant devices.
プロトコルはほぼ同一であるため（schismとaltの変更を処理するルールを除く）、すべてのユーザーとマーチャントのデバイスにインストールされているソフトウェアを簡単に更新できます。

If someone just wants to start a new coin to experiment with another set of protocol rules, he can also use the ‘alt’ field to inherit everything from the old coin, make the switch comfortable for users, and have a large set of users with balances from day one.
誰かが別のプロトコルルールを試すために新しいコインを開始したい場合は、「alt」フィールドを使用して古いコインのすべてを継承し、スイッチを快適にし、 1日目からのバランス。

18. Skiplist

1. スキップリスト

Some of the balls contain a skiplist array which enables faster building of proofs for light clients (see below).
いくつかのボールには、軽量クライアント用の証明書を素早く作成するためのskiplist配列が含まれています（下記参照）。

Only those balls that lie directly on the MC, and whose MC index is divisible by 10, have a skiplist.
MCに直接横たわっていて、MC指数が10で割り切れるボールだけがスキップリストを持っています。

The skiplist lists the nearest previous MC balls whose index has the same or smaller number of zeros at the end.
スキップリストには、インデックスの末尾にゼロの数が同じか少ない数の最も近い以前のMCボールがリストされます。

For example, the ball at MCI 190 has a skiplist that references the ball at MCI 180.
たとえば、MCI 190のボールには、MCI 180のボールを参照するスキップリストがあります。

The ball at MCI 3000 has a skiplist that references the balls at MCIs 2990, 2900, and 2000.
MCI 3000のボールには、MCI 2990,2900、および2000のボールを参照するskiplistがあります。

19. Light clients

1. ライトクライアント

Light clients do not store the entire Byteball database.
ライトクライアントは、Byteballデータベース全体を格納しません。

Instead, they download a subset of data they are interested in, such as only transactions where any of the user’s addresses are spending or being funded.
代わりに、ユーザーのアドレスのいずれかが支出している、または資金提供されているトランザクションなど、関心のあるデータのサブセットをダウンロードします。

Light clients connect to full nodes to download the units they are interested in.
ライトクライアントは、フルノードに接続して、目的のユニットをダウンロードします。

The light client tells the full node the list of witnesses it trusts (not necessarily the same witnesses it uses to create new units) and the list of its own addresses.
ライトクライアントは、信頼する証人のリスト（必ずしも新しいユニットを作成するために使用する同じ証人ではない）とそれ自身のアドレスのリストを完全ノードに伝えます。

The full node searches for units the light client is interested in and constructs a proof chain for each unit in the following way:
フルノードは、ライトクライアントが興味を持っているユニットを検索し、以下の方法で各ユニットのプルーフチェーンを構築します。

1. Walk back in time along the MC until the majority of requested witnesses are met. Collect all these MC units.
2. From the last unit in this set (which is also the earliest in time), read the last ball.
3. Starting from this last ball, walk back in time along the MC until any ball with a skiplist is met. Collect all these balls.
4. Using the skiplist, jump to an earlier ball referenced from the skiplist. This ball also has a skiplist, jump again. Where there are several balls in skiplist array, always jump by the largest distance possible, so we accelerate jumping first by 10 indexes, then by 100, then by 1000, etc.
5. If the next jump by the skiplist would throw us behind the target ball, decelerate by jumping by a smaller distance. Ultimately, leave the skiplist and walk along the MC one index at a time using just parent links.

1.要請された証人の大半が満たされるまで、MCに沿って時間をかけて歩きます。これらのMCユニットをすべて集めてください。
2.このセットの最後のユニット（時間的にも最も早いユニット）から、最後のボールを読みます。
3.この最後のボールからスタートし、スケート練習をしたボールが出るまでMCに沿って時間を戻します。これらのボールをすべて集めてください。
4.スキップリストを使用して、スキップリストから参照される以前のボールにジャンプします。このボールにもスキップがあり、再びジャンプする。スキップリスト配列に複数のボールがある場合は、常に可能な限り最大距離だけジャンプするので、最初に10個のインデックス、次に100個、次に1000個ずつジャンプします。
5.スキップ師による次のジャンプが目標ボールの後ろに私たちを投げた場合、より小さな距離でジャンプすることによって減速する。結局のところ、skiplistを離れ、親リンクだけを使用してMCインデックスに沿って歩いてください。

This chain has witness-authored units in the beginning, making it trustworthy from the light client’s point of view.
このチェーンは最初に証人作成のユニットを持ち、ライトクライアントの観点から信頼できるものにします。

All the elements of the chain are linked by either parent unit links (while accumulating the witnesses), or by last ball reference, or by parent ball links, or by skiplist links.
チェーンのすべての要素は、親ユニットのリンク（目撃者の蓄積中）、または最後のボール参照、親ボールリンク、またはスキップリンクリンクによってリンクされます。

At the end of the chain, we have the unit whose existence was to be proved.
チェーンの終わりには、その存在が証明されるユニットがあります。

20. Multilateral signing

1. 多国間署名

A unit can be signed by multiple parties. In such instances, the authors array in the unit has two or more elements.
ユニットには複数の当事者が署名することができます。そのような場合、ユニットの作者配列には2つ以上の要素があります。

This can be useful, for example. if two or more parties want to sign a contract (a plain old dumb contract, not a smart one).
これは、例えば有用であり得る。 2人以上の当事者が契約に署名したい場合（スマートなものではなく、単純な古いダム契約）。

They would both sign the same unit that contains a text message (app=’text’).
彼らは両方とも、テキストメッセージ（app = 'text'）を含む同じユニットに署名します。

They don’t have to store the full text of the contract in the public database, and pay for it – a hash would suffice (payload_location=’none’), and the parties themselves can store the text privately. Another application of multilateral signing is an exchange of assets.
彼らは、契約の全文を公のデータベースに保管しておかなくても、それを支払う必要はありません。ハッシュで十分です（payload_location = 'none'）。そして、当事者自身がテキストを個人的に保管することができます。多国間署名のもう一つの用途は、資産の交換です。

Assume user A wants to send asset X to user B in exchange for asset Y (the native currency ‘bytes’ is also an asset – the base asset).
ユーザAは、資産Yと引き換えに資産XをユーザBに送信することを望んでいると仮定する（ネイティブ通貨「バイト」も資産であり、ベース資産である）。

Then they would compose a unit that contains two payment messages: one payment sends asset X from A to B, the other payment sends asset Y from B to A.
次に、2つの支払いメッセージを含むユニットを構成します.1つの支払いは、AからBへ資産Xを送信し、もう1つの支払いは、BからAに資産Yを送信します。

They both sign the dual-authored unit and publish it.
彼らはデュアルオーサリングされたユニットに署名し、それを公開します。

The exchange is atomic – that is, either both payments execute at the same time or both fail.
交換はアトミックです。つまり、両方の支払いが同時に実行されるか、または両方が失敗します。

If one of the payments appears to be a double-spend, the entire unit is rendered invalid and the other payment is also deemed void.
いずれかの支払いが二重支出と見なされると、ユニット全体が無効とされ、他の支払いも無効とみなされます。

This simple construction allows users to exchange assets directly, without trusting their money to any centralized exchanges.
このシンプルな構成により、ユーザーは集中管理された取引所にお金を信じることなく資産を直接交換することができます。

21. Addresses

1. アドレス

Users are identified by their addresses, transaction outputs are sent to addresses, and, like in Bitcoin, it is recommended that users have multiple addresses and avoid reusing them. In some circumstances, however, reuse is normal.
ユーザーはアドレスで識別され、トランザクション出力はアドレスに送信され、Bitcoinの場合と同様に、複数のアドレスを持ち、それらを再利用することは避けてください。しかし、場合によっては再利用が正常です。

For example, witnesses are expected to repeatedly post from the same address.
たとえば、証人は同じ住所から繰り返し投稿することが予想されます。

An address represents a definition, which is a Boolean expression (remotely similar to Bitcoin script).
アドレスは定義を表し、これはブール式です（Bitcoinスクリプトと似ています）。

When a user signs a unit, he also provides a set of authentifiers (usually ECDSA signatures) which, when applied to the definition, must evaluate it to true in order to prove that this user had the right to sign this unit.
ユーザがユニットに署名するとき、ユーザは、このユーザがこのユニットに署名する権利を有することを証明するために、定義に適用されるときにそれを真に評価しなければならない認証者のセット（通常はECDSA署名）も提供する。

We write definitions in JSON.
定義はJSONで記述します。

For example, this is the definition for an address that requires one ECDSA signature to sign:
たとえば、これは、ECDSA署名が1つ必要なアドレスの定義です。

["sig",{"pubkey":"Ald9tkgiUZQQ1djpZgv2ez7xf1ZvYAsTLhudhvn0931w"}]

The definition indicates that the owner of the address has a private key whose public counterpart is given in the definition (in base64 encoding), and he will sign all units with this private key.
この定義は、住所の所有者が、公開の相手が（base64エンコーディングの）定義で与えられた秘密鍵を持っていることを示し、この秘密鍵ですべてのユニットに署名します。

The above definition evaluates to true if the signature given in the corresponding authentifier is valid, or otherwise false.
上記の定義は、対応する認証者で与えられた署名が有効であるか、そうでなければfalseである場合に真と評価されます。

The signature is calculated over all data of the unit except the authentifiers.
署名は、認証者以外のユニットのすべてのデータにわたって計算されます。

Given a definition object, the corresponding address is just a hash of the initial definition object plus a checksum.
定義オブジェクトが与えられると、対応するアドレスは、初期定義オブジェクトとチェックサムのハッシュにすぎません。

The checksum is added to avoid typing errors. Unlike usual checksum designs, however, the checksum bits are not just appended to the end of the unchecksummed data. Rather, they are inserted into multiple locations inside the data.
入力エラーを避けるためにチェックサムが追加されました。しかし、通常のチェックサムデザインとは異なり、チェックサムビットはチェックされていないデータの最後に付加されるだけではありません。むしろ、それらはデータ内の複数の場所に挿入されます。

This design makes it hard to insert long strings of illegal data in fields where an address is expected.
この設計により、アドレスが予想されるフィールドに長いデータ列の文字列を挿入することが難しくなります。

The address is written in base32 encoding.
アドレスは、base32エンコーディングで記​​述されます。

The above definition corresponds to address A2WWHN7755YZVMXCBLMFWRSLKSZJN3FU.
上記の定義はアドレスA2WWHN7755YZVMXCBLMFWRSLKSZJN3FUに対応しています。

When an address is funded, the sender of the payment knows and specifies only the address (the checksummed hash of the definition) in the payment output.
住所が資金提供されると、支払いの送付者は支払い出力の住所（定義のチェックサム付きハッシュ）のみを認識し指定します。

The definition is not revealed and it remains unknown to anyone but the owner until the output is spent.
定義は明らかにされておらず、出力が費やされるまで所有者以外の誰にも分かりません。

When a user sends his first unit from an address, he must reveal its definition (so as to make signature verification possible) in the authors array:
ユーザーがアドレスから最初のユニットを送信するときには、authors配列にその署名の検証を可能にするためにその定義を表示する必要があります。

unit: {
    …
    authors: [ {
        address: 'DJ6LV5GPCLMGRW7ZB55IVGJRPDJPOQU6',
        definition: [
            "sig",
            {"pubkey":"AsnvZ3w7N1lZGJ+P+bDZU0DgOwJcGJ51bjsWpEqfqB
            g6"}
        ],
        authentifiers: {
            r:
            '3eQPIFiPVLRwBwEzxUR5thqn+zlFfLXUrzAmgemAqOk35UvDpa4h
            79Fd6TbPbGfb8VMiJzqdNGHCKyAjl786mw=='
        }
    } ],
    …
}

If the user sends a second unit from the same address, he must omit the definition (it is already known on Byteball).
ユーザーが同じアドレスから2番目のユニットを送信した場合、ユーザーは定義を省略しなければなりません（これはByteballで既に認識されています）。

He can send the second unit only after the definition becomes stable, i.e. the unit where the definition was revealed must be included in the last ball unit of the second unit.
彼は、定義が安定した後にのみ、第2のユニットを送ることができる。すなわち、定義が明らかにされたユニットは、第2のユニットの最後のボールユニットに含まれなければならない。

Users can update definitions of their addresses while keeping the old address.
ユーザーは、古い住所を保持しながら住所の定義を更新できます。

For example, to rotate the private key linked to an address, the user needs to post a unit that contains a message such as:
たとえば、アドレスにリンクされた秘密鍵をローテーションするには、次のようなメッセージを含むユニットを投稿する必要があります。

unit: {
    …
    messages: [
        …
        {
            app: "address_definition_change",
            definition_chash: "I4Z7KFNIYTPHPJ5CA5OFC273JQFSZPOX"
        },
        …
    ],
    …
}

Here, definition_chash indicates the checksummed hash of the new address definition (which is not revealed until later), and the unit itself must be signed by the old private keys.
ここで、definition_chashは、新しいアドレス定義のチェックサム付きハッシュ（後で明らかにされない）を示し、ユニット自体は古い秘密鍵によって署名されなければならない。

The next unit from this address must:
• include this address_definition_change unit in its last ball unit, i.e. it must be already stable;
• reveal the new definition in the authors array in the same way as for the first message from an address.
このアドレスの次の単位は、
• 最後のボールユニットにこのaddress_definition_changeユニットを含めます。つまり、すでに安定していなければなりません。
• アドレスからの最初のメッセージと同じ方法で、authors配列に新しい定義を表示する。

After the change, the address is no longer equal to the checksummed hash of its current definition.
変更後、アドレスは現在の定義のチェックサム付きハッシュと等しくなりません。

Rather, it remains equal to the checksummed hash of its initial definition.
むしろ、初期定義のチェックサム付きハッシュと等しくなります。

The definition change is useful if the user wants to change the key(s) (e.g. when migrating to a new device) while keeping the old address, e.g. if this address already participates in other long-lived definitions (see below).
定義変更は、古いアドレスを保持しながらユーザがキーを変更したい場合（例えば新しいデバイスに移行する場合）に有用である。このアドレスが既に他の長期定義に参加している場合（下記参照）

21.1. Definition syntax

21.1. 定義構文

21.1.1. Logical operators

21.1.1. 論理演算

A definition can include “and” conditions, for example:
定義には「and」条件を含めることができます。たとえば、次のようになります。

["and", [
    ["sig", {pubkey: "one pubkey in base64"}],
    ["sig", {pubkey: "another pubkey in base64"}]
]]

which is useful when, in order to sign transactions, signatures from two independent devices are required, for example, from a laptop and from a smartphone.
これは、トランザクションに署名するために、例えばラップトップやスマートフォンなどの2つの独立したデバイスからの署名が必要な場合に便利です。

“Or” conditions, such as this:
"Or"条件：

["or", [
    ["sig", {pubkey: "laptop pubkey"}],
    ["sig", {pubkey: "smartphone pubkey"}],
    ["sig", {pubkey: "tablet pubkey"}]
]]

are useful when a user wants to use the same address from any of his devices.
The conditions can be nested:
ユーザーがいずれかのデバイスから同じアドレスを使用したい場合に便利です。
条件は入れ子にすることができます：

["and", [
    ["or", [
        ["sig", {pubkey: "laptop pubkey"}],
        ["sig", {pubkey: "tablet pubkey"}]
    ]],
    ["sig", {pubkey: "smartphone pubkey"}]
]]

A definition can require a minimum number of conditions to be true out of a larger set, for example, a 2-of-3 signature:
定義では、より大きい集合の中で最小数の条件が真であることを要求することができます（例えば、2-of-3署名）。

["r of set", {
    required: 2,
    set: [
        ["sig", {pubkey: "laptop pubkey"}],
        ["sig", {pubkey: "smartphone pubkey"}],
        ["sig", {pubkey: "tablet pubkey"}]
    ]
}]

(“r” stands for “required”) which features both the security of two mandatory signatures and the reliability, so that in case one of the keys is lost, the address is still usable and can be used to change its definition and replace the lost 3rd key with a new one.
（「r」は「必須」を表す）、2つの必須署名のセキュリティと信頼性の両方を備えているため、鍵の1つが失われた場合でも、アドレスは引き続き使用可能であり、その定義を変更し、新しいもので3番目のキーを失った。

Also, different conditions can be given different weight, of which a minimum is required:
また、異なる条件に異なる重みを与えることができ、そのうちの最小限のものが必要とされる。

["weighted and", {
    required: 50,
    set: [
        {weight: 40, value: ["sig", {pubkey: "CEO pubkey"}] },
        {weight: 20, value: ["sig", {pubkey: "COO pubkey"}] },
        {weight: 20, value: ["sig", {pubkey: "CFO pubkey"}] },
        {weight: 20, value: ["sig", {pubkey: "CTO pubkey"}] }
    ]
}]

21.1.2 Delegation to other addresses

21.1.2 他のアドレスへの委任

An address can contain reference to another address:
アドレスは別のアドレスへの参照を含むことができます：

["and", [
    ["address", "ADDRESS 1 IN BASE32"],
    ["address", "ADDRESS 2 IN BASE32"]
]]

which delegates signing to another address and is useful for building shared control addresses (addresses controlled by several users).
署名を別のアドレスに委任し、共有制御アドレス（複数のユーザによって制御されるアドレス）を構築するのに便利です。

This syntax gives the users the flexibility to change definitions of their own component addresses whenever they like, without bothering the other user.
この構文により、ユーザーは、いつでも他のユーザーを気にすることなく、独自のコンポーネントアドレスの定義を自由に変更できます。

21.1.3 Signatures and authentifiers

21.1.3 署名と認証子

In most cases, a definition will include at least one signature (directly or indirectly):
ほとんどの場合、定義には少なくとも1つの署名（直接的または間接的）が含まれます。

["sig", {pubkey: "pubkey in base64"}]

Instead of a signature, a definition may require a preimage for a hash to be provided:
署名の代わりに、定義には、ハッシュを提供するためのプリイメージが必要な場合があります。

["hash",{"hash":"value of sha256 hash in base64"}]

which can be useful for cross-chain exchange algorithms [7].
これは、クロスチェーン交換アルゴリズム[7]に有用であり得る。

In this case, the hash preimage is entered as one of the authentifiers.
この場合、ハッシュ・プリイメージは認証者の1人として入力されます。

The default signature algorithm is ECDSA on curve secp256k1 (same as Bitcoin).
デフォルトの署名アルゴリズムは、曲線secp256k1のECDSAです（Bitcoinと同じ）。

Initially, it is the only algorithm supported.
最初は、サポートされている唯一のアルゴリズムです。

If other algorithms are added in the future, algorithm identifier will be used in the corresponding part of the definition, such as for the quantum secure NTRU algorithm:
将来他のアルゴリズムが追加されると、クォンムセキュアNTRUアルゴリズムのように、定義の対応する部分でアルゴリズム識別子が使用されます。

["sig", {algo: "ntru", pubkey: "NTRU public key in base64"}]

Multisignature definitions allow one to safely experiment with unproven signature schemes when they are combined with more conventional signatures.
マルチシグネチャの定義では、従来のシグネチャと組み合わせた場合、証明されていないシグネチャスキームを安全に試すことができます。

The authentifiers object in unit headers contains signatures or other data (such as hash preimage) keyed by the path of the authentifier-requiring subdefinition within the address definition.
ユニットヘッダー内の認証オブジェクトには、アドレス定義内の認証子要求副規則のパスによってキーされた署名またはその他のデータ（ハッシュプリイメージなど）が含まれます。

For a single-sig address such as
シングルサインアドレスの場合

["sig", {pubkey: "pubkey in base64"}]

the path is simply “r” (r stands for root).
パスは単に "r"（rはルートを表します）です。

If the authentifier-requiring subdefinition is included within another definition (such as and/or), the path is extended by an index into the array where this subdefinition is included, and path components are delimited by a dot.
認証子を必要とするサブ定義が（および/またはなどの）別の定義内に含まれる場合、このサブ定義が含まれている配列内のインデックスによってパスが拡張され、パスコンポーネントはドットで区切られます。

For example, for address definition:
たとえば、アドレス定義の場合は次のようになります。

["and", [
    ["sig", {pubkey: "one pubkey in base64"}],
    ["sig", {pubkey: "another pubkey in base64"}]
]]

the paths are “r.0” and “r.1”.
パスは「r.0」と「r.1」です。

For a deeper nested definition:
深いネストされた定義の場合：

["and", [
    ["or", [
        ["sig", {pubkey: "laptop pubkey"}],
        ["sig", {pubkey: "tablet pubkey"}]
    ]],
    ["sig", {pubkey: "smartphone pubkey"}]
]]

the paths are “r.0.0”, “r.0.1”, and “r.1”.
パスは「r.0.0」、「r.0.1」、「r.1」です。

When there are optional signatures, such as 2-of-3, the paths tell us which keys were actually used.
2-of-3のようなオプションのシグネチャがある場合、パスは実際に使用されたキーを示します。

21.1.4 Definition templates

21.1.4 定義テンプレート

A definition can also reference a definition template:
定義は定義テンプレートを参照することもできます。

["definition template", [
    "hash of unit where the template was defined",
    {param1: "value1", param2: "value2"}
]]

The parameters specify values of variables to be replaced in the template.
パラメータは、テンプレート内で置き換えられる変数の値を指定します。

The template needs to be saved before (and as usual, be stable before use) with a special message type app=’definition_template’, the template itself is in message payload, and the template looks like normal definition but may include references to variables in the syntax @param1, @param2.
特別なメッセージタイプapp = 'definition_template'でテンプレートを保存する必要があります（通常は使用前に安定している必要があります）。テンプレート自体はメッセージペイロードにあり、テンプレートは通常の定義のように見えますが、構文@param1、@ param2。

Definition templates enable code reuse.
定義テンプレートはコードの再利用を可能にします。

They may in turn reference other templates.
彼らはまた、他のテンプレートを参照するかもしれません。

21.1.5 Cosigning

21.1.5 共生

A subdefinition may require that the unit be cosigned by another address:
サブディビジョンでは、ユニットを別のアドレスでコサインする必要があります。

["cosigned by", "ANOTHER ADDRESS IN BASE32"]

21.1.6 Querying whether an address was used

21.1.6 アドレスが使用されたかどうかの問い合わせ

Another possible requirement for a subdefinition: that an address was seen as author in at least one unit included into the last ball unit:
細分化のための別の可能な要件：アドレスが最後のボールユニットに含まれる少なくとも1つのユニットの著者として見られたこと。

["seen address", "ANOTHER ADDRESS IN BASE32"]

21.1.7 Data feeds

21.1.7 データフィード

One very useful condition can be used to make queries about data previously stored in Byteball:
Byteballに以前に格納されたデータに関するクエリを作成するのに、非常に有用な条件の1つを使用できます。

["in data feed", [
    ["ADDRESS1", "ADDRESS2", …],
    "data feed name",
    "=",
    "expected value"
]]

This condition evaluates to true if there is at least one message that has "data feed name" equal to "expected value" among the data feed messages authored by the listed addresses "ADDRESS1", "ADDRESS2", .. (oracles).
この条件は、リストされたアドレス「ADDRESS1」、「ADDRESS2」、..（oracles）によって作成されたデータフィードメッセージの中で、「期待値」に等しい「データフィード名」を有する少なくとも1つのメッセージが存在する場合、真と評価される。

Data feed is a message type that looks like this:
データフィードは、次のようなメッセージタイプです。

unit: {
    …
    messages: [
        …
        {
            app: "data_feed",
            payload_location: "inline",
            payload_hash: "hash of payload",
            payload: {
                "data feed name": "value",
                "another data feed name": "value2",
            …
            }
        },
        …
    ],
    …
}

Data fields can be used to design definitions that involve oracles.
データフィールドは、oraclesを含む定義を設計するために使用できます。

If two or more parties trust a particular entity (the oracle) to provide true data, they can set up a shared control address that gives the parties different rights depending on data posted by the oracle(s).
複数の当事者が特定のエンティティ（オラクル）が真のデータを提供することを信頼する場合、オラクルによってポストされたデータに応じて当事者に異なる権利を与える共有制御アドレスを設定することができます。

For example, this address definition represents a binary option:
たとえば、このアドレス定義はバイナリオプションを表します。

["or", [
    ["and", [
        ["address", "ADDRESS 1"],
        ["in data feed", [["EXCHANGE ADDRESS"], "EURUSD", ">",
        "1.1500"]]
        ]],
    ["and", [
        ["address", "ADDRESS 2"],
        ["in data feed", [["TIMESTAMPER ADDRESS"], "datetime", ">",
        "2016-10-01 00:00:00"]]
    ]]
]]

Initially, the two parties fund the address defined by this definition (to remove any trust requirements, they use multilateral signing and send their stakes in a single unit signed by both parties).
当初、両当事者はこの定義で定義された住所に資金を提供します（信用要件を取り除くために、多国間署名を使用し、両当事者が署名した単一の単位でステークスを送信します）。

Then if the EUR/USD exchange rate published by the exchange address ever exceeds 1.1500, the first party can sweep the funds.
その後、交換所で発行されたEUR / USD為替レートが1.1500を超えると、ファーストパーティーが資金を払うことができます。

If this doesn’t happen before Oct 1, 2016 and the timestamping oracle posts any later date, the second party can sweep all funds stored on this address.
これが2016年10月1日より前に起こらず、タイムスタンプオラクルが後日投稿した場合、第2当事者はこの住所に保管されているすべての資金を掃引することができます。

If both conditions are true and the address balance is still non-empty, both parties can try to take the money from it at the same time, and the double-spend will be resolved as usual.
両方の条件が満たされ、住所の残高がまだ空でない場合は、両当事者が同時にお金を払うことができ、二重支出はいつものように解決されます。

The comparison operators can be "=", "!=", ">", ">=", "<", and "<=".
比較演算子は、 "="、 "！="、 ">"、 "> ="、 "<"、 "<="のいずれかです。

The data feed message must come before the last ball unit as usual.
データフィードメッセージは、通常のように最後のボールユニットの前に来なければなりません。

To reduce the risks that arise in case any single oracle suddenly goes offline, several feed provider addresses can be listed.
単一のオラクルが突然オフラインになった場合に発生するリスクを軽減するために、いくつかのフィードプロバイダのアドレスを一覧表示することができます。

Another example would be a customer who buys goods from a merchant but he doesn’t quite trust that merchant and wants his money back in case the goods are not delivered.
もう1つの例は、商人から商品を購入する顧客であるが、その商人をあまり信用しておらず、商品が配送されない場合には彼のお金を元に戻すことを望む。

The customer pays to a shared address defined by:
顧客は、以下によって定義される共有アドレスに支払う。

["or", [
    ["and", [
        ["address", "MERCHANT ADDRESS"],
        ["in data feed", [["FEDEX ADDRESS"], "tracking", "=",
        "123456"]]
        ]],
    ["and", [
        ["address", "BUYER ADDRESS"],
        ["in data feed", [["TIMESTAMPER ADDRESS"], "datetime", ">",
        "2016-10-01 00:00:00"]]
    ]]
]]

The definition depends on the FedEx oracle that posts tracking numbers of all successfully delivered shipments.
定義は、正常に配送されたすべての出荷の追跡番号を記載したFedExのオラクルによって異なります。

If the shipment is delivered, the merchant will be able to unlock the money using the first condition.
出荷が配送される場合、商人は最初の条件を使用してお金をロック解除することができます。

If it is not delivered before the specified date, the customer can take his money back.
指定された日付より前に配送されない場合、顧客はお金を取り戻すことができます。

This example is somewhat crazy because it requires FedEx to post each and every shipment.
この例は、FedExが各貨物を発送する必要があるため、多少狂っています。

21.1.8 Merkle data feeds

21.1.8 Merkleデータフィード

For a more realistic way to achieve the same goal, there is another syntax:
同じ目標を達成するためのより現実的な方法として、別の構文があります。

["in merkle", [
    ["ADDRESS1", "ADDRESS2", …],
    "data feed name",
    "hash of expected value"
]]

which evaluates to true if the specified hash of expected value is included in any of the merkle roots posted in the data feed from addresses "ADDRESS1", "ADDRESS2",…
期待値の指定されたハッシュが、アドレス "ADDRESS1"、 "ADDRESS2"、...のデータフィードに投稿されたいずれかのメルクルルーツに含まれている場合、真と評価されます。

Using this syntax, FedEx would only periodically post merkle roots of all shipments completed since the previous posting.
この構文を使用すると、FedExは、前回の転記以降に完了したすべての出荷のMerkle Rootを定期的に投稿します。

To spend from this address, the merchant would have to provide the merkle path that proves that the specified value is indeed included in the corresponding merkle tree.
このアドレスから費やすために、マーチャントは、指定された値が実際に対応するメルクルツリーに含まれていることを証明するメルクルパスを提供する必要があります。

The merkle path is supplied as one of the authentifiers.
Merkleパスは、認証者の1人として提供されます。

21.1.9 Self-inspection

21.1.9 自己検査

A definition can also include queries about the unit itself.
定義には、ユニット自体についてのクエリも含めることができます。

This subdefinition
この下位定義

['has', {
    what: 'input'|'output',
    asset: 'assetID in base64 or "base" for bytes',
    type: 'transfer'|'issue',
    own_funds: true,
    amount_at_least: 123,
    amount_at_most: 123,
    amount: 123,
    address: 'INPUT OR OUTPUT ADDRESS IN BASE32'
}]

evaluates to true if the unit has at least one input or output (depending on the ‘what’ field) that passes all the specified filters, with all filters being optional.
ユニットに、指定されたすべてのフィルタを渡す少なくとも1つの入力または出力（「フィールド」に応じて）があり、すべてのフィルタがオプションである場合は、trueに評価されます。

A similar condition ‘has one’ requires that there is exactly one input or output that passes the filters.
同様の条件「1を有する」は、フィルタを通過させる入力または出力がちょうど1つであることを必要とする。

The ‘has’ condition can be used to organize a decentralized exchange.
「持っている」状態は、分散された交換を組織化するために使用することができる。

Previously, we discussed the use of multilateral signing to exchange assets.
以前は、資産を交換するための多国間署名の使用について議論しました。

However, multilateral signing alone doesn’t include any mechanism for price negotiation.
しかし、多国間の調印だけでは、価格交渉の仕組みは含まれていない。

Assume that a user wants to buy 1,200 units of another asset for which he is willing to pay no more than 1,000 bytes.
ユーザが1,000バイト以下を支払うことを望む別の資産の1,200単位を購入したいと仮定する。

Also, he is not willing to stay online all the time while he is waiting for a seller.
また、彼は売り手を待っている間、常にオンラインにとどまっていません。

He would rather just post an order at an exchange and let it execute when a matching seller comes along.
彼はちょうど交換所で注文を掲示し、一致する売り手が来たらそれを実行させます。

He can create a limit order by sending 1,000 bytes to an address defined by this definition:
彼は、この定義で定義されたアドレスに1,000バイトを送信することによって制限注文を作成することができます。

["or", [
    ["address", "USER ADDRESS"],
    ["and", [
        ["address", "EXCHANGE ADDRESS"],
        ["has", {
            what: "output",
            asset: "ID of alternative asset",
            amount_at_least: 1200,
            address: "USER ADDRESS"
        }]
    ]]
]]

The first or-alternative lets the user take back his bytes whenever he likes, thus cancelling the order.
第1の代替方法は、ユーザが好きなときにいつでもバイトを取り戻すことができるため、注文を取り消すことができます。

The second alternative delegates the exchange the right to spend the funds, provided that another output on the same unit pays at least 1,200 units of the other asset to the user’s address.
第2の選択肢は、同じユニットの別のアウトプットが、他の資産の少なくとも1,200単位をユーザの住所に支払うという条件で、交換機に資金を使う権利を委任する。

The exchange would publicly list the order, a seller would find it, compose a unit that exchanges assets, and multilaterally sign it with the exchange.
取引所は注文を公表し、売り手はそれを見つけ、資産を交換するユニットを構成し、取引所に多国籍で署名する。

One can also use the ‘has’ condition for collateralized lending.
また、有担保融資のために「有する」条件を使用することもできます。

Assume a borrower holds some illiquid asset and needs some bytes (or another liquid asset).
借り手が非流動資産を保有していて、いくつかのバイト（または別の流動資産）が必要であると仮定します。

The borrower and a lender can then multilaterally sign a unit.
借り手と貸し手は、多国籍で1つのユニットに署名することができます。

One part of the unit sends the bytes he needs to the borrower, the other part of the unit locks the illiquid asset into an address defined by:
ユニットの一部は、必要なバイトを借り手に送信し、ユニットの他の部分は、非流動資産を以下で定義されるアドレスにロックします。

["or", [
    ["and", [
        ["address", "LENDER ADDRESS"],
        ["in data feed", [["TIMESTAMPER ADDRESS"], "datetime", ">",
        "2017-06-01 00:00:00"]]
        ]],
    ["and", [
        ["address", "BORROWER ADDRESS"],
        ["has", {
            what: "output",
            asset: "base",
            amount: 10000,
            address: "LENDER ADDRESS"
        }]
    ]],
    ["and", [
        ["address", "LENDER ADDRESS"],
        ["address", "BORROWER ADDRESS"]
    ]]
]]

The first or-alternative allows the lender to seize the collateral if the loan is not paid back in time.
第1または代替案は、ローンが時間内に返済されない場合、貸し手が担保を差し押さえることを可能にする。

The second alternative allows the borrower to take back the collateral if he also makes a payment of 10,000 bytes (the agreed loan size including interest) to the lender.
2番目の選択肢は、借り手が貸し手に10,000バイト（利息を含む合意されたローンサイズ）の支払いを行う場合に、借り手が担保を取り戻すことを可能にすることです。

The third alternative allows the parties to amend the terms if they both agree.
第3の選択肢は、両当事者が同意する場合、両当事者が条件を修正することを可能にするものです。

The following requirement can also be included in a subdefinition:
以下の要件は、さらに定義に含めることができます。

['has equal', {
    equal_fields: ['address', 'amount'],
    search_criteria: [
        {what: 'output', asset: 'asset1', address: 'BASE32'},
        {what: 'input', asset: 'asset2', type: 'issue', own_funds:
        true, address: 'ANOTHERBASE32'}
    ]
}]

It evaluates to true if there is at least one pair of inputs or outputs that satisfy the search criteria (the first element of the pair is searched by the first set of filters; the second by the second) and some of their fields are equal.
検索条件を満たす入力または出力のペアが少なくとも1つ（ペアの最初の要素は最初のフィルタセットで検索され、2番目は2番目のフィルタで検索されます）、フィールドのいくつかが等しい場合、真と評価されます。

A similar condition ‘has one equal’ requires that there is exactly one such pair.
同様の条件「1つの等しい」は、そのようなペアが1つだけ存在することを要求する。

Another subdefinition may compare the sum of inputs or outputs filtered according to certain criteria to a target value or values:
別の下位定義では、ある基準に従ってフィルタリングされた入力または出力の合計を1つまたは複数の目標値と比較することができる。

['sum', {
    filter: {
        what: 'input'|'output',
        asset: 'asset or base',
        type: 'transfer'|'issue',
        own_funds: true,
        address: 'ADDRESS IN BASE32'
    },
    at_least: 120,
    at_most: 130,
    equals: 123
}]

21.1.10 Negation

21.1.10 否定

Any condition that does not include “sig”, “hash”, “address”, “cosigned by”, or “in merkle” can be negated:
"sig"、 "hash"、 "address"、 "cosigned by"、 "in merkle"を含まない条件は否定できます：

["not", ["in data feed", [["NOAA ADDRESS"], "wind_speed", ">",
"200"]]]

Since it is legal to select very old parents (that didn’t see the newer data feed posts), one usually combines negative conditions such as the above with the requirement that the timestamp is after a certain date.
非常に古い親を選択することは合法であるため（新しいデータフィード投稿が表示されない）、通常、上記のような否定的な条件と、タイムスタンプが特定の日付の後の要件とを組み合わせます。

21.2 Generalrequirements

21.2 一般的な要件

Address definition must have at least one “sig”, explicitly or implicitly (such as through an “address”).
アドレス定義には、少なくとも1つの "sig"が明示的または暗黙的に含まれていなければなりません（例えば、 "アドレス"など）。

To avoid consuming too many resources for validation, the total number of operations is limited to 100 per definition, including operations in referenced definitions such as “address” and “definition template”.
検証に必要なリソースが多すぎるのを避けるため、「アドレス」や「定義テンプレート」などの参照定義の操作を含め、操作の総数は定義ごとに100に制限されます。

This number is one of just 9 arbitrary constants that we have in Byteball, the other 8 being: total number of witnesses: 12; max allowed mutations: 1; max number of MC indexes for a witness to get paid: 100; number of parents counted for header size: 2; max number of messages per unit: 128; max number of inputs or outputs per message: 128; max number of authors per unit: 16; and total money supply: 1015.
この数字は、私たちがByteballで持っているちょうど9つの定数のうちの1つであり、他の8つは：
目撃者の総数：12;
最大許容変異：1;
証人が支払われるMCインデックスの最大数：100;
ヘッダーサイズのために数えられた親の数：2;
単位あたりの最大メッセージ数：128;
メッセージ当たりの入力または出力の最大数：128;
単位あたりの最大著者数：16;
総貨幣供給量は10**15である。

For comparison, Bitcoin has at least 17 constants [8], while Ethereum defines 30 constants for fee schedule alone [9].
比較のために、Bitcoinは少なくとも17個の定数を持っていますが、Ethereumは料金スケジュールだけで30個の定数を定義しています[9]。

Note that the definition language described above is declarative and consists entirely of Boolean statements, which puts it closer to the language of conventional legal contracts.
上記の定義言語は宣言的であり、完全にブールステートメントで構成されているため、従来の法的契約の言語に近いものになります。

However, in terms of its expressive power, the language does not come anywhere close to Ethereum smart contracts language.
しかし、表現力の面では、Ethereumのスマートコントラクト言語に近い言語は得られません。

In fact, it doesn’t even allow for a trivial ‘Hello world’ program to be written.
実際、それは簡単な「Hello world」プログラムを書くことさえ許さない。

This was not our goal.
これは私たちの目標ではありませんでした。

The Byteball definition language was not designed to be comprehensive; rather, it is designed to be comprehensible to the greatest possible number of people, who are not necessarily programmers.
Byteball定義言語は包括的に設計されていませんでした。むしろ、必ずしもプログラマーではない可能性のある最大限の人に理解できるように設計されています。

Its straightforward syntax allows everyone to interpret and compose simple definitions without the help of a developer (a “lawyer” for the era of smart contracts), and chances of mistakes are minimized.
その簡単な構文は、開発者（スマート契約の時代の「弁護士」）の助けなしに誰もが簡単な定義を解釈して構成することを可能にし、間違いの可能性は最小限に抑えられます。

22. Profiles

1. プロフィール

Users can store their profiles on Byteball if they want.
ユーザーは必要に応じてByteballにプロファイルを保存できます。

They use a message like this:
彼らは次のようなメッセージを使用します：

unit: {
    …
    messages: [
        ….
        {
            app: "profile",
            payload_location: "inline",
            payload_hash: "hash of payload",
            payload: {
                name: "Joe Average",
                emails: ["[e-mail]", "[e-mail]"],
                twitter: "joe"
            }
        },
        …
    ],
    …
}

The amount of data they disclose about themselves, as well as its veracity, is up to the users themselves.
彼らが自分自身について開示するデータの量とその真実性は、ユーザー自身の責任です。

To be assured that any particular information about a user is true, one has to look for attestations.
ユーザーに関する特定の情報が真実であることを保証するためには、アテステーションを探す必要があります。

23. Attestations

1. アテステーション

Attestations confirm that the user who issued the attestation (the attestor) verified some data about the attested user (the subject).
アテステーションは、アテステーション（アテスター）を発行したユーザーが、アテストされたユーザー（サブジェクト）に関するデータを確認したことを確認します。

Attestations are stored in messages like this:
アテステーションは次のようなメッセージに格納されます。

unit: {
    …
    messages: [
        …
        {
            app: "attestation",
            payload_location: "inline",
            payload_hash: "hash of payload",
            payload: {
                address: "ADDRESS OF THE SUBJECT"
                profile: {
                    name: "Joe Average",
                    emails: ["[e-mail]"]
                }
            }
        },
        …
    ],
    …
}

The information included in the attestation need not be the same as in user’s selfpublished profile.
アテステーションに含まれる情報は、ユーザーの自己パブリッシュされたプロファイルと同じである必要はありません。

Indeed, the self-published profile might not even exist at all.
確かに、自己発行のプロフィールは全く存在しないかもしれません。

The job of attestors is similar to that of modern certification authorities who verify the real-world identities of subjects and certify that a particular public key (or Byteball address) does belong to a person or organization.
アテスターの仕事は、現実の主体のアイデンティティを検証し、特定の公開鍵（またはByteballアドレス）が個人または組織に属していることを証明する現代の認証機関の仕事に似ています。

We expect them to continue the same activity in Byteball and charge a fee from those who want to prove a link between their real-world and Byteball identities.
私たちは、彼らがByteballで同じ活動を続け、現実世界とByteballのアイデンティティの間のつながりを証明したい人から手数料を請求することを期待しています。

Witnesses and would-be witnesses will likely want to receive some attestations to increase their trust.
目撃者と証人になる人は、信頼を高めるためにいくつかの証言を受け取りたいと思うでしょう。

Certain asset types may require attestations to transact with the asset (see below).
特定の資産タイプでは、アセットが資産と取引する必要があります（下記参照）。

For applications where an attestation is required but the name of the subject is not important, it is possible to omit the name or other personally identifiable information in the attested profile.
アテステーションが必要であるが、サブジェクトの名前が重要でないアプリケーションの場合、アテストされたプロファイル内の名前またはその他の個人識別可能な情報を省略することができます。

The attested profile may even not include any meaningful information about the subject at all, thus leaving him anonymous to everybody but the attestor.
証明されたプロファイルは、被験者に関する意味のある情報をまったく含んでいなくてもよく、したがって、彼を証人以外の誰にでも匿名にする。

The attestor will still keep records about the subject and may disclose them under certain circumstances, as specified in the attestor’s terms or if required by law.
アテスターは依然として被験者に関する記録を保持し、アテスターの条件で指定された特定の状況下で、または法律で要求される場合には、それらを開示することがあります。

24. Assets

1. アセット

We have designed a database that allows immutable storage of any data.
私たちは、あらゆるデータの不変な記憶を可能にするデータベースを設計しました。

Of all classes of data, the most interesting for storage in a common database are those that have social value, i.e. the data that is valuable for more than one or two users.
すべてのクラスのデータのうち、共通のデータベースにおける記憶のために最も興味深いものは、社会価値を有するもの、すなわち、1人または2人以上のユーザにとって価値のあるデータである。

One such class is assets.
そのようなクラスの1つが資産です。

Assets can be owned by anybody among a large number of people, and the properties of immutability and total ordering of events that we have in Byteball are very important for establishing the validity of long chains of ownership transfers.
資産は多くの人の誰かが所有することができ、Byteballでの不変性やイベントのトータルオーダーは、所有権移転の長いチェーンの正当性を確立する上で非常に重要です。

Assets in Byteball can be issued, transferred, and exchanged, and they behave similarly to the native currency ‘bytes’.
Byteballの資産は発行、移転、交換が可能で、元の通貨「バイト」と同様に動作します。

They can represent anything that has value, for example debt, shares, loyalty points, airtime minutes, commodities, other fiat or crypto currencies.
彼らは、例えば借金、株式、ロイヤリティポイント、通話時間分、コモディティ、その他の金銭または暗号通貨など、価値のあるものを表すことができます。

To define a new asset, the defining user sends a message like this:
新しいアセットを定義するには、定義ユーザーが次のようなメッセージを送信します。

unit: {
    …
    messages: [
        …
        {
            app: "asset",
            payload_location: "inline",
            payload_hash: "hash of payload",
            payload: {
                cap: 1000000,
                is_private: false,
                is_transferrable: true,
                auto_destroy: false,
                fixed_denominations: false,
                issued_by_definer_only: true,
                cosigned_by_definer: false,
                spender_name_attested: true,
                attestors: [
                    "2QLYLKHMUG237QG36Z6AWLVH4KQ4MEY6",
                    "X5ZHWBYBF4TUYS35HU3ROVDQJC772ZMG"
                ]
            }
        },
        …
    ],
    …
}

Here:
ここに:

• cap is the maximum amount that can be issued. For comparison with the predefined native currency bytes, the bytes cap is 1015;
• is_private indicates if the asset is transferred privately or publicly (see below). Bytes are public;
• is_transferrable indicates if the asset can be transferred between third parties without passing through the definer of the asset. If not transferrable, the definer must always be either the only sender or the only receiver of every transfer. Bytes are transferrable;
• auto_destroy indicates if the asset is destroyed when it is sent to the definer. Bytes are not auto-destroyed;
• fixed_denominations indicates if the asset can be sent in any integer amount (arbitrary amounts) or only in fixed denominations (e.g. 1, 2, 5, 10, 20, etc), which is the case for paper currency and coins. Bytes are in arbitrary amounts;
• issued_by_definer_only indicates if the asset can be issued by definer only. For bytes, the entire money supply is issued in the genesis unit;
• cosigned_by_definer indicates if every transfer must be cosigned by the definer of the asset. This is useful for regulated assets. Transfers in bytes needn’t be cosigned by anybody;
• spender_attested indicates if the spender has to be attested in order to spend. If he happened to receive the asset but is not yet attested, he has to pass attestation with one of the attestors listed under the definition, in order to be able to spend. This requirement is also useful for regulated assets. Bytes do not require attestation;
• attestors is the list of attestor addresses recognized by the asset definer (only if spender_attested is true). The list can be later amended by the definer by sending an ‘asset_attestors’ message that replaces the list of attestors;
• denominations (not shown in this example and used only for fixed_denominations assets) lists all allowed denominations and total number of coins of each denomination that can be issued;
• transfer_condition is a definition of a condition when the asset is allowed to be transferred. The definition is in the same language as the address definition, except that it cannot reference anything that requires an authentifier, such as “sig”. By default, there are no restrictions apart from those already defined by other fields;
• issue_condition is the same as transfer_condition but for issue transactions.
• capは発行可能な最大額です。定義済みのネイティブ通貨バイトとの比較のために、バイト上限は1015です。
• is_privateは、資産が非公開で公開されているかどうかを示します（下記参照）。バイトはパブリックです。
• is_transferrableは、資産の定義者を通過せずに第三者間で資産を転送できるかどうかを示します。転送が不可能な場合、定義者は常に各転送の唯一の送信者または受信者のいずれかでなければなりません。バイトは転送可能です。
• auto_destroyは、資産が定義者に送信されたときに破棄されるかどうかを示します。バイトは自動的に破棄されません。
• fixed_denominationsは、資産を任意の整数量（任意の金額）で、または固定金額（1,2,5,10,20など）で送ることができるかどうかを示します。これは、紙幣や硬貨の場合です。バイト数は任意です。
• issued_by_definer_onlyは、資産が定義者だけが発行できるかどうかを示します。バイトの場合、マネーサプライ全体は起源ユニットで発行されます。
• cosigned_by_definerは、すべての転送が資産の定義者によってコサインされる必要があるかどうかを示します。これは、規制された資産に役立ちます。バイト単位の転送は、誰にでもコサインされる必要はありません。
• spender_attestedは、費やすために出産者を証明する必要があるかどうかを示します。彼が資産を受け取ったにもかかわらず、まだ証明されていない場合、彼は費やすことができるために、定義の下にリストアップされた証人の1人に証拠を渡さなければなりません。この要件は規制された資産にも有用です。バイトはアテステーションを必要としません。
• attestorsは、資産定義者が認識したアテスターアドレスのリストです（spender_attestedがtrueの場合のみ）。このリストは、アテスタのリストを置き換える 'asset_attestors'メッセージを送信することによって、定義者によって後で修正することができます。
• 金種（この例では表示されておらず、fixed_denominations資産のみに使用されています）は、発行可能なすべての金種と各金種のコインの総数を列挙します。
• transfer_conditionは、資産の転送が許可されたときの条件の定義です。この定義は、 "sig"のような認証子を必要とするものは参照できないという点を除けば、アドレス定義と同じ言語になります。デフォルトでは、他のフィールドで既に定義されているものを除いて、制限はありません。
• issue_conditionは、transfer_conditionと同じですが、問題のトランザクションの場合です。

There can be no more than 1 ‘asset’ message per unit.

単位あたり1つの「資産」メッセージがあります。

After the asset is defined, it is identified by the hash of the unit where it was defined (hence the 1 asset per unit requirement).
アセットが定義されると、アセットが定義されたユニットのハッシュによって識別されます（したがって、ユニット要件ごとに1つのアセット）。

A transfer of an asset looks like a transfer of bytes, the difference being that there is an extra field for the asset ID:
アセットの転送はバイトの転送のように見えますが、その違いはアセットIDの余分なフィールドがあることです

unit: {
    …
    messages: [
        …
        {
            app: "payment",
            payload_location: "inline",
            payload_hash: "hash of payload",
            payload: {
                asset: "hash of unit where the asset was
                defined",
                inputs: [
                    {
                        unit: "hash of source unit",
                        message_index: 0,
                        output_index: 1
                    },
                    …
                ],
                outputs: [
                    {
                        address: "BENEFICIARY ADDRESS",
                        amount: 12345
                    },
                    …
                ]
            }
        },
        …
    ],
    …
}

Before it can be transferred, an asset is created when a user sends an issue transaction.
転送できるようになる前に、ユーザーが発行トランザクションを送信するとアセットが作成されます。

Issue transactions have a slightly different format for inputs:
問題取引は、入力の形式が若干異なります。

unit: {
    …
    messages: [
        …
        {
            app: "payment",
            payload_location: "inline",
            payload_hash: "hash of payload",
            payload: {
                asset: "hash of unit where the asset was
                defined",
                inputs: [
                    {
                        type: "issue",
                        amount: 1000000,
                        serial_number: 1,
                        address: "ISSUER ADDRESS" // only
                        when multi-authored
                    },
                    …
                ],
                outputs: [
                    {
                        address: "BENEFICIARY ADDRESS",
                        amount: 12345
                    },
                    …
                ]
            }
        },
        …
    ],
    …
}

The entire supply of capped arbitrary-amounts assets must be issued in a single transaction.
上限のある任意の金額の資産の全供給は、単一の取引で発行する必要があります。

In particular, all bytes are issued in the genesis unit.
特に、すべてのバイトは起源ユニットで発行されます。

If the asset is capped, the serial number of the issue must be 1.
アセットに上限が設定されている場合、問題のシリアル番号は1でなければなりません。

If it is not capped, the serial numbers of different issues by the same address must be unique.
上限が設定されていない場合は、同じ住所による異なる発行の通し番号が一意でなければなりません。

An asset is defined only once and cannot be amended later, only the list of attestors can be amended.
資産は一度だけ定義され、後で修正することはできません。アテスターのリストのみを修正することができます。

It’s up to the definer of the asset what this asset represents.
この資産が表すものは、資産の定義者次第です。

If it is issuer’s debt, it is reasonable to expect that the issuer is attested or waives his anonymity to earn the trust of the creditors.
それが発行者の債務である場合、債権者の信頼を得るために発行者が証明されることを期待するか、または匿名を放棄することが妥当である。

While end users are free to use or not to use an asset, asset definers can impose any requirements on transactions involving the asset.
エンドユーザーは自由に資産を使用することができますが、資産を使用することはできませんが、資産定義者は資産に関わるトランザクションにあらゆる要件を課すことができます。

By combining various asset properties the definer can devise assets thatsatisfy a wide range of requirements, including those that regulated financial institutions have to follow.
さまざまな資産特性を組み合わせることにより、金融機関が規制しなければならないものを含め、幅広い要件に適合する資産を開発者が考案することができます。

For example, by requiring that each transfer be cosigned by the definer, financial institutions can effectively veto all payments that contradict any regulatory or contractual rules.
例えば、金融機関は、規制当局や契約上の規則に反するすべての支払いを効果的に拒否することができます。

Before cosigning each payment, the financial institution (who is also the definer and the issuer) would check that the user is indeed its client, that the recipient of the funds is also a client, that both clients have passed all the Know Your Client (KYC) procedures, that the funds are not arrested by a court order, as well as carry out any other checks required by the constantly changing laws, regulations, and internal rules, including those that were introduced after the asset was defined.
各支払いを協調させる前に、金融機関（定義者および発行者でもある）は、ユーザーが実際にクライアントであること、資金の受領者もクライアントであること、両方のクライアントがすべてのKnow Your Client (KYC)手順に合格したこと、ファンドは裁判所命令によって逮捕されることはなく、資産の定義後に導入されたものを含め、絶えず変化する法律、規則、および社内規則によって要求されるその他の検査を実施する。

24.1 Bank issued assets

24.1 銀行発行の資産

Having the security of being fully compliant (and also assured in the familiar deterministic finality of all funds transfers), banks can issue assets that are pegged to national currencies and backed by the bank’s assets (which are properly audited and monitored by the central banks).
銀行は、完全に準拠していることを保証されており（また、すべての資金移動の決定的な最終決定でも保証されている）、国の通貨に固定され、銀行の資産（中央銀行によって適切に監査および監視される） 。

The legal nature of any operations with such assets is exactly the same as with all other bank money, and is familiar to everybody.
そのような資産を持つ事業の法的性質は、他のすべての銀行の資金とまったく同じであり、誰にでも親しまれています。

The only novelty is that the balances and transfers are tracked in Byteball database instead of the bank’s internal database. Being tracked in Byteball database has two consequences:
唯一の新規性は、銀行の内部データベースではなく、バイトボールデータベースで残高と振替が追跡されることです。 Byteballデータベースで追跡されることには、2つの結果があります。

• (a not so welcome one) all operations are public, which is familiar from Bitcoin and mitigated by using multiple semi-anonymous addresses of which only the bank knows the real persons behind the addresses. Another more robust way to preserve privacy is private payments, which we’ll discuss later;
• (a good one) the bank-issued asset can be exchanged for bytes or other assets on-chain, in a peer-to-peer manner, without having to trust any third parties such as exchanges.
• すべての操作は公開されているため、Bitcoinに慣れており、複数の半匿名アドレスを使用することで軽減されます。プライバシーを保護するもうひとつのより堅牢な方法は、私的支払いです。これについては後で説明します。
• 銀行発行資産は、取引所などの第三者を信頼することなく、ピアツーピア方式で、チェーン上のバイトまたはその他の資産と交換することができます。

The banks here are similar to Ripple gateways.
ここの銀行はリップル・ゲートウェイに似ています。

In the exchange scenario above, one leg of the exchange is payment from one user to another user in a bank-issued asset.
上記の交換シナリオでは、交換の1つのレッグは、銀行発行の資産の1人のユーザーから別のユーザーへの支払いです。

If both users are clients of the same bank, this process is straightforward.
両方のユーザーが同じ銀行のクライアントである場合、このプロセスは簡単です。

When users hold accounts at different banks, the banks may facilitate the interbank transfers by opening correspondent accounts at each other.
ユーザーが異なる銀行で口座を保有している場合、銀行はお互いに取引口座を開設することによって銀行間取引を容易にすることができる。

Let’s assume user U1 wants to transfer money to user U2 in circumstances where user U1 holds an account at bank B1 and user U2 holds an account at bank B2.
ユーザU1が銀行B1に口座を保持し、ユーザU2が銀行B2に口座を保持する状況において、ユーザU1がユーザU2に資金を移転したいと仮定しよう。

Bank B2 also opens an account at B1. U1 then transfers the money to B2’s account at B1 (it is an internal bank transfer within B1 which is cosigned by B1).
また、銀行B2はB1で口座を開設する。その後、U1はB1のB2の口座に金銭を振り込みます（B1の内部銀行振替であり、B1によってコスピ払われます）。

At the same time, B2 (which has just increased its assets at B1) issues new money to its user U2.
同時に、B2（B1で資産を増やしたばかり）は、ユーザU2に新しい金額を発行します。

All this must be atomic.
これはすべて原子でなければなりません。

All three participants: (U1, B1, and B2) must therefore sign a single unit that both transfers B1’s money from U1 to B2 and issues B2’s money to U2.
したがって、3人の参加者（U1、B1、およびB2）は、B1のお金をU1からB2に転送し、B2のお金をU2に発行する単一のユニットに署名する必要があります。

The net result is that U1 decreased his balance at B1, U2 increased his balance at B2, and B2 increased his balance at B1.
正味の結果は、U1はB1でのバランスを減少させ、U2はB2でのバランスを増加させ、B2はB1でのバランスを増加させた。

The bank B1 will also have a correspondent account at B2, the balance of which will grow as reverse payments are processed from users of B2 to users of B1.
また、銀行B1にはB2のコルレス勘定があり、その残高はB2のユーザーからB1のユーザーに逆払いが処理されるにつれて増加します。

The mutual obligations (B1 at B2 and B2 at B1) can be partially cancelled by the banks mutually signing a transaction that sends equal amounts to the respective issuer (it is convenient to have the money auto-destroyed by sending it to the issuer).
相互義務（B1のB2とB2のB1）は、それぞれの発行者に等しい金額を送信する取引に相互に署名する銀行によって部分的に取り消すことができます（発行者に送付することによって金銭を自動破棄するのが便利です）。

What is not cancelled can be periodically settled through traditional interbank payments.
取り消されないものは、伝統的な銀行間支払いを通じて定期的に決済することができます。

To trigger the settlement, the bank with a positive net balance sends his balance to the issuer bank, and since there is no reverse transfer in the same transaction, this triggers a traditional payment in fiat money from the issuer to the holder bank.
決済をトリガするために、正味の純残高を有する銀行は、残高を発行者銀行に送り、同じ取引で逆振替がないので、発行者から保有者銀行への伝統的な決済がトリガされる。

When there are many banks, setting up direct correspondent relations with each peer bank can be cumbersome.
多くの銀行がある場合、各ピア銀行との直接的な取引関係を設定することは面倒である可能性がある。

In such instances, the banks agree about a central counterparty C (a large member bank or a new institution) and pass all payments exclusively through this central counterparty and settle only with it.
そのような場合、銀行は中央のカウンターパーティーC（大加盟銀行または新機関）について同意し、この中央カウンターパーティーを通してすべての支払いを専有し、それだけで決済する。

The same transfer from U1 to U2 will then consist of 3 transactions:
U1からU2への同じ転送は、3つのトランザクションで構成されます。

1. U1 sends money to C’s account at B1;
2. C issues own money to B2 (or C destroys B2’s money it held by returning it to B2);
3. B2 issues its own money to U2.
4. U1はB1のCの口座にお金を送ります。 2.CはB2に自分のお金を出す（またはCはそれをB2に返すことによって保有したB2のお金を破壊する）。
5. B2は自分のお金をU2に発行します。

All 3 transactions are bundled into a single unit and signed by U1, B1 (as the required cosigner for all U1’s transactions), C, and B2.
3つのトランザクションはすべて1つのユニットにまとめられ、U1、B1（すべてのU1のトランザクションに必要な補助者）、CおよびB2によって署名されます。

24.2 Non-financial assets

24.2 非金融資産

Other applications that are not necessarily financial can use Byteball assets internally.
必ずしも財務的ではない他のアプリケーションでは、内部的にByteball資産を使用することができます。

For example, loyalty programs may issue loyalty points as assets and use Byteball’s existing infrastructure to allow people to transact in these points, including peer-to-peer (if allowed by the program’s rules).
例えば、ロイヤルティプログラムはロイヤルティポイントを資産として発行し、Byteballの既存のインフラストラクチャを使用して、ピアツーピア（プログラムのルールによって許可されている場合）を含む人々がこれらのポイントで取引できるようにすることができます。

The same is true for game developers, who can track game assets on Byteball.
Byteballでゲーム資産を追跡できるゲーム開発者にも同じことが当てはまります。

24.3 Bonds

24.3 債券

Businesses can issue bonds on Byteball.
企業はByteballで債券を発行することができます。

The legal structure of the issue is the same as for conventional bonds, the only difference being that the depository will now track bond ownership using Byteball rather than an internal database (similar to banks above). Having bonds in Byteball enables their holders to trade directly, without a centralized exchange.
問題の法的構造は従来の債券と同じですが、唯一の違いは、預金者が内部データベースではなくByteballを使用して債券の所有権を追跡することです（上記の銀行に似ています）。 Byteballに債券を保有することで、保有者は一元的な取引をせずに直接取引することができます。

When bank money is also on Byteball, an instant delivery versus payment (a fiat payment in this context) becomes possible, without counterparty risk and without any central institution.
銀行のお金がByteballにもある場合、カウンターパーティのリスクなしに、中央機関がなくても、インスタント・デリバリと支払い（この文脈では決済）が可能になります。

The title to the bond and payment are exchanged simultaneously as the parties sign the same unit that performs both transfers.
両当事者が両方の移転を実行する同じユニットに署名すると同時に、債券と支払いの肩書が交換されます。

Bonds, if liquid enough, can also be used by third parties as a means of payment.
債券は、十分な流動性を有する場合には、支払い手段として第三者にも使用することができます。

When a bond is issued, the issuer and the investor would multilaterally sign a common unit that sends the newly issued bonds to the investor and at the same time sends bytes (or another asset used to purchase the bonds, such as a bankissued fiat-pegged asset) from the investor to the borrower.
債券が発行されると、発行者と投資家は、新たに発行された債券を投資家に送る共通の単位に署名し、同時にバイト（または債券の購入に使用される別の資産、資産）を投資家から借り手に還元する。

When the bond is redeemed, they sign another multilateral unit that reverses the exchange (most likely, at a different exchange rate).
債券が償還されるとき、彼らは交換を逆転する別の多国間機関に署名する（おそらく、異なる為替レートで）。

The price of the bond paid during redemption is its face value, while the price it is sold for when issued must be lower than the face value to reflect interest (assuming zero coupon bond for simplicity).
償還時に支払われる債券の価格は額面価格であり、発行時に売却された価格は利子を反映するために額面価格よりも低くなければなりません（単純化のためクーポン債がゼロと仮定）。

During its lifetime, the secondary market price of the bond stays below face value and gradually approaches it.
一生の間、債券の二次市場価格は額面価格を下回り、徐々にそれに近づいています。

In a growing economy where there are many projects to finance, bonds and other debt issued on Byteball to finance investment will be issued more often than they are redeemed.
資金調達のプロジェクトが多い成長経済では、投資を賄うためにByteballに発行された債券やその他の債務が、償還されるよりも頻繁に発行されます。

When the economy slows down, the total supply of all bonds shrinks, as there are fewer projects to finance.
景気が減速すると、資金調達するプロジェクトが少なくなるため、すべての債券の総供給が減少します。

Thus, the total supply of bonds self regulates, which is important if they are actively used as a means of payment.
したがって、債券の総供給は自己規制されており、支払い手段として積極的に利用される場合には重要です。

If two businesses transact on net-30 terms, both buyer and seller have the option to securitize the trade credit during the 30-day period.
2つの事業がネット30の条件で取引する場合、買い手と売り手の両方は、30日間の期間に取引クレジットを証券化するオプションを有する。

For example, the buyer can issue 30-day bonds and use them to pay the seller immediately.
例えば、買い手は30日間の債券を発行し、売り手に即座に支払いを行うことができます。

The seller can then either wait for the 30 days to pass and redeem the bonds, or use the bonds as a means of payment to its own suppliers.
売り手は30日間を過ぎて債券を償還するか、債券を自らの供給業者に支払うことができます。

In this case, it will be the suppliers who redeem the bonds when they mature.
この場合、満期になると債券を償還するのは仕入先になります。

24.4 Commodity onds

24.4 コモディティ債

Bonds can be issued in natural units, not just in currencies.
債券は、通貨だけでなく、自然単位で発行することができます。

For example, a 100-barrel bond entitles its holder to receive 100 barrels of oil when the bond matures; a 1kWh bond entitles the holder to receive 1 kWh of electricity.
例えば、100バレルの債券は、債券が満期になると、その所有者が100バレルの油を受け取ることができます。 1kWhの債券は、1kWhの電力を受け取る権利を持ちます。

The holder may also choose to receive the monetary equivalent of the 100 barrels or 1 kWh at the price that is current on the maturity date.
保有者はまた、満期日現在の価格で、100バレルまたは1kWhの金銭相当額を受け取ることを選択することができる。

Such bonds (commodity bonds) are in fact very useful for hedging risks.
実際、そのような債券（商品債）はリスクをヘッジするために非常に有用です。

Consider a new oil project that takes many years and large investment before it even starts commercial operation. If financing is sought only in national currencies, the project may never be financed because of uncertain oil prices at the time the new facility starts selling oil.
商業運転を開始する前に、長年の投資と多額の投資が必要な新しい石油プロジェクトを考えてみましょう。ファイナンシングが国内通貨でのみ求められる場合、新規施設が石油を販売する時期に不確実な原油価格があるため、プロジェクトは決して資金調達されない可能性があります。

The creditors have to consider the risk that the price will be too low, and as a result the borrower will have to default.
債権者は、価格が低すぎるというリスクを考慮する必要があり、その結果、借り手は債務不履行を起こさなければならない。

Creditors want the risk priced into the interest rate, which means the interest rate becomes too high, and the project never happens.
債権者は、リスクが金利に値上がりされることを望んでいます。これは、金利が高すぎることを意味し、プロジェクトは決して起こらないということです。

However, if the project operator could borrow in barrels, the risk of default drastically decreases.
しかし、事業者がバレルで借り入れることができれば、債務不履行のリスクは大幅に減少する。

Now, the project will likely start as planned and will likely produce the planned volume of oil.
現在、計画は計画どおりに開始され、計画された量の石油が生産される可能性が高い。

It will hence be able to produce and repay all the borrowed barrels within the specified time.
したがって、指定された時間内にすべての借入れされたバレルを生産し、返済することができます。

There are still other risks, but one huge risk – the market risk – is removed.
それでもなお他のリスクがありますが、市場リスクである巨大なリスクが取り除かれます。

It is removed from the borrower but shifted to the lenders who now have to consider the chances that oil prices go down and they receive less (in currency terms) than invested.
これは借り手から削除されましたが、現在は原油価格が下がり、投資よりも（通貨換算で）受け取る可能性を考慮しなければならない貸し手に移りました。

On the other hand, if the prices go up, the lenders get additional profit from the price difference (note that by borrowing in barrels, the borrower waives this upside potential), and there are always investors willing to take a position in a commodity.
一方、価格が上がると、貸し手は価格差から利益を得る（樽で借りることによって借り手がこの潜在的な可能性を放棄することに注意）、常に商品でポジションをとる投資家がいる。

Since the bond is traded on Byteball, the lenders can easily sell it whenever they like.
債券はByteballで取引されているので、貸し手はいつでも好きなときにそれを売ることができます。

Unlike oil futures, whose trading is a zero-sum game, the investment in commodity bonds does finance the industry.
取引がゼロサムゲームである石油先物とは異なり、コモディティ債に対する投資は業界に資金を提供する。

Also, oil futures are a short-term instrument, while commodity bonds allow one to buy and hold, which is more suitable to long term investors.
また、石油先物は短期金融商品であり、コモディティ社債は買い通しが可能であり、長期投資家にとってはより適している。

There is another category of potential lenders – those who hedge against the opposite risk.
潜在的な貸し手のもう一つのカテゴリ - 反対のリスクをヘッジする人がいる。

For example, airlines would like to hedge against an increase of oil prices, and one way to do that is by buying commodity bonds of oil producing companies, which one expects to correlate with oil prices.
例えば、航空会社は原油価格の上昇を回避することを望んでおり、その方法の1つは原油価格と相関すると予想される石油生産会社のコモディティ債を購入することである。

The above is true for any commodity, e.g. electricity, iron ore, gold, other metals, crops, etc.
上記はすべての商品に当てはまります。電気、鉄鉱石、金、その他の金属、作物など。

From the borrower’s perspective, commodity bonds can be thought of as a way to sell future production at today’s prices.
借り手の観点から見ると、コモディティ債は将来の生産を今日の価格で売る方法と考えることができます。

For the lender, it is a way to buy future supplies at today’s prices.
貸し手にとって、それは今日の価格で将来の供給を購入する方法です。

If a substantial part of the economy runs on commodity bonds, the leverage cycle is naturally smoothed out even without government intervention since during recessions falling commodity prices automatically reduce the amount of debt.
経済の大部分が商品債で稼働している場合、景気後退期に商品価格が下落すると自動的に負債の額が減少するため、政府の介入なしにもレバレッジ・サイクルは自然に平滑化されます。

24.5 Funds

24.5 資金

For individual users, it might be difficult to track the huge number of bonds that are available on the market.
個々のユーザーにとって、市場で利用可能な膨大な数の債券を追跡するのは難しいかもしれません。

Instead, they would rather choose to invest in funds that are professionally managed and hold a large diversified portfolio of bonds.
代わりに、専門的に管理され、大きな多様化した債券ポートフォリオを保有するファンドに投資することを選択します。

The fund would issue its own asset that tracks the aggregate value of the fund’s portfolio.
ファンドは、ファンドのポートフォリオの総価値を追跡する独自の資産を発行する。

Every time an investor buys a newly issued asset of the fund, the fund would use the proceeds to buy bonds.
投資家が新たに発行されたファンドの資産を購入するたびに、ファンドはその収益を債券の購入に使用する。

When a user exits, the fund sells some of the bonds it held and destroys the fund-issued assets returned by the user.
ユーザーが退出すると、ファンドは保有している債券の一部を売却し、ユーザーが返却したファンド発行資産を破棄します。

The fund’s asset is not capped; its total supply varies as investors enter and exit.
ファンドの資産には上限がありません。投資家が出入りするにつれてその供給量は変化する。

Its value is easily auditable as all the bonds held by the fund are visible on Byteball.
ファンドが保有するすべての債券がByteball上に表示されるので、その価値は簡単に監査可能です。

Being more liquid than the underlying bonds, the fund’s asset has higher chances of becoming a means of payment.
基礎となる債券より流動性が高いため、ファンドの資産は支払手段になる可能性が高くなります。

24.6 Settlements

24.6 決済

A group of banks can use assets for interbank settlements.
銀行のグループは、銀行間決済のために資産を使用することができます。

Some of the larger banks issue fiat-pegged assets that can only be used by attested users, and only group members can be attested.
大手銀行の中には、証明されたユーザーのみが使用できる平等な資産を発行するものもあれば、グループメンバーだけを証明できるものもあります。

The asset is backed by the issuing bank’s reserves.
資産は、発行銀行の引当金により裏付けられている。

When a smaller bank wants to settle with another smaller bank, it just sends the asset.
小さな銀行が別の小さな銀行と決済したい場合、それは資産を送信するだけです。

The receiving bank can use the asset in the same way to settle with other banks, or redeem it for fiat currency with the issuing bank.
受取側銀行は、同じ方法で他の銀行との決済や発行銀行との通貨換金を行うことができます。

The banks can also exchange USD-pegged assets for EUR-pegged assets or similar.
銀行はまた、EURペッグド資産またはそれに類するものについて、米ドル建ての資産を交換することもできる。

All suchtransfers and trades are settled immediately, they are final and irrevocable.
そのような取引と取引はすべて即座に解決され、最終的かつ取消不能です。

In SWIFT, banks exchange only information about payments, while the actual transfer of money is a separate step.
SWIFTでは、銀行は支払いに関する情報のみを交換しますが、実際の送金は別のステップです。

In Byteball, information is money.
Byteballでは、情報はお金です。

25. Private payments

1. 私的支払い

So far, we have considered only payments that are sent in the open, i.e. their payloads are included inline and visible to everybody.
これまでは、開かれた状態で送信される支払いのみを考慮しました。つまり、ペイロードはすべての人にインラインで表示されます。

Remember that Byteball allows the posting of private payloads: the user keeps the payload private (payload_location=’none’) but posts only its hash to be able to prove that the payload existed at a specific time. To apply that to payments, the sender of the funds also needs to send the private payload to the recipient via private communication channels.
Byteballはプライベートペイロードのポスティングを許可することを覚えておいてください。ユーザはペイロードをプライベート（payload_location = 'none'）にしておきますが、ペイロードが特定の時刻に存在したことを証明できるようにハッシュのみをポストします。これを支払いに適用するには、資金の送付者は私的通信チャネルを介して受取人に個人のペイロードを送る必要もあります。

The recipient would need to look up the payload hash in Byteball to confirm that it existed.
受信者はByteball内のペイロードハッシュを調べて、それが存在することを確認する必要があります。

However, that is not enough as having concealed the payload content from other Byteball nodes we also removed their ability to verify that the same output is not spent twice.
しかし、それは他のByteballノードからペイロードコンテンツを隠してしまったので十分ではありません。同じ出力が2回使われていないことを検証する能力もなくなりました。

To restore this ability, we add an additional public field into the unit. This field is called spend proof, and it is constructed in such way that:
この能力を回復するために、追加のパブリックフィールドをユニットに追加します。このフィールドは、「支出証明」と呼ばれ、以下のように構成されています。

• it depends solely on the output being consumed, so that an attempt to spend the same output again will produce the same spend proof;
• it doesn’t reveal anything about the output being spent.
• 消費される出力のみに依存するため、同じ出力を再試行すると同じ消費見本が作成されます。
• 使用されているアウトプットについて何も明らかにしていない。

It is easy to see that this construction satisfies the above requirements:
この構成が上記の要件を満たすことは容易にわかります。

spend_proof = hash({
    asset: payload.asset,
    unit: input.unit,
    message_index: input.message_index,
    output_index: input.output_index,
    address: src_output.address,
    amount: src_output.amount,
    blinding: src_output.blinding
})

Here, payload.asset is the ID of the asset being privately transferred, input refers to the input that consumes a previous output src_output.
ここで、payload.assetは私的に転送されている資産のIDです。入力は以前の出力src_outputを消費する入力を参照します。

Private outputs should have an extra field called blinding, which is just a random string designed to make it impossible to pre-image the consumed output knowing its spend proof (all the other fields come from a rather narrow set of possible values that can be iterated through within a reasonable timeframe).
プライベート出力にはblindingと呼ばれる余分なフィールドが必要です。これは、消費された出力を事前にイメージ化することを不可能にするために設計されたランダムな文字列です（他のすべてのフィールドは、反復可能な値合理的な時間枠内で）。

The above spend proof construction applies to transfers.
上記の費用のかかる構成は、移転に適用されます。

For issues:
問題について：

spend_proof = hash({
    asset: payload.asset,
    address: "ISSUER ADDRESS",
    serial_number: input.serial_number, // always 1 for capped
    assets
    amount: input.amount, // issue amount
    denomination: 1 // always 1 for arbitrary-amounts payments
})

Note that spend proof for issue transaction does not include any blinding factor.
発行取引の費用見積もりには、盲目的要因は含まれていないことに注意してください。

As such it is possible to learn that a coin was issued, but the recipient of the coin is still hidden from third parties.
このように、コインが発行されたことを知ることは可能ですが、コインの受取人は依然として第三者から隠されています。

Also, for transfer transactions, since the payer knows the blinding factor, he can calculate the spend proof that’ll be published when the coin is spent. This means that he can know when the payee spends the coin, but he will not see the recipient(s) nor the new blinding factor(s) – and hence will not be able to track the coin any further.
また、移転取引の場合、支払人は盲目的要因を知っているので、コインが消費されたときに発行される出費証明書を計算することができます。これは、受取人がいつコインを使うのかを知ることができますが、受取人や新しい目立たない要因を見ないため、コインをそれ以上追跡することができなくなります。

Spend proofs are added into the unit:
支出証明がユニットに追加されます：

unit: {
    …
    spend_proofs: [
        {
            spend_proof: "the above hash in base64",
            address: "SPENDING ADDRESS" // only if multi-authored
        },
        …
    ],
    …
}

Thus, to send a private payment, the sending user should:
したがって、個人の支払いを送信するには、送信ユーザーは次の操作を行う必要があります。

• add a random blinding factor to each output;
• not publish the payload but send it to the payee privately, along with the hash of the unit where this payload can be found;
• for each input, add the corresponding spend proof into the unit. All validators should reject a unit if they see the same spend proof posted from the same address again (provided that the address posts serially, of course).
• 各出力にランダムなブラインディング係数を追加する。
• ペイロードを公開するのではなく、このペイロードが見つかるユニットのハッシュと一緒に、受取人に非公開で送信します。
• 各入力に対して、対応する支出証明をユニットに追加します。すべてのバリデーターは、同じ住所から再度同じ郵送証明書が送られてくるのを見たら、ユニットを拒否しなければなりません。

The payee should check that (1) the payload he received privately does hash to payload_hash posted to Byteball by the payer and (2) the spend proofs derived from private payload inputs match those included in the unit.
受取人は、（1）個人で受け取ったペイロードが、支払人によってByteballにポストされたpayload_hashをハッシュし、（2）プライベートペイロード入力から得られた支出証明がユニットに含まれるものと一致することを確認する必要があります。

When a user who received a private payment wants to spend its outputs, he has to forward the private payloads he has received to the new payee, so that the new payee can verify the entire chain of ownership transfers (the history) back to the point where the asset was issued.
プライベートペイメントを受け取ったユーザーがアウトプットを使いたい場合は、受け取ったプライベートペイロードを新しい受取人に転送しなければなりません。そのため、新しい受取人は、資産が発行された場所。

The length of the history will grow with each transfer.
履歴の長さは転送ごとに大きくなります。

Note that with the format of payment we have considered so far, each unit can merge outputs from several previous units and produce several new outputs (most often, two).
これまで検討してきた支払いのフォーマットでは、各ユニットは以前のユニットからの出力をマージし、いくつかの新しい出力（多くの場合、2つ）を生成することができます。

Each previous unit, in turn, depends on several even earlier units, and each output will be later split into several new outputs.
以前の各ユニットは、さらにいくつかの以前のユニットに依存しており、各出力は後にいくつかの新しい出力に分割されます。

Therefore, the number of future units that have at least some “blood” of the initial unit grows exponentially with time. Conversely, the number of ancestors that contribute to the unit’s inputs grows exponentially with the number of steps back in history.
したがって、最初のユニットの少なくともいくらかの「血液」を有する将来のユニットの数は、時間とともに指数関数的に増加する。逆に、ユニットの投入に寄与する祖先の数は、歴史的に後退したステップの数とともに指数関数的に増加する。

To avoid such rapid growth of histories, we need to limit the divisibility of the coins, and this is where an asset type with fixed_denominations property set to true proves useful.
このような歴史の急速な成長を避けるためには、コインの分割可能性を制限する必要があります。これはfixed_denominationsプロパティがtrueに設定されたアセットタイプが有用であることを証明します。

26. Fixed denominations assets

1. 固定金額資産

A fixed denominations asset exists as a set of indivisible unmergeable coins, very
similar to the minted coins and banknotes that everybody is familiar with.
固定金種資産は、分割不可能な分割不可能な硬貨のセットとして存在します。
みんながよく知っている貨幣や紙幣に似ています。

The amount of every coin must be one of a small set of allowed denominations, which should be selected so that it is convenient to represent any practical amount with maximum accuracy and the smallest number of coins.
すべてのコインの金額は、許可された金種の小さなセットの1つでなければならず、実際の金額を最高の精度と最小のコインで表すのが便利であるように選択する必要があります。

Most modern currency systems have denominations that follow a 1-2-5 pattern: 1, 2, 5, 10, 20, 50, 100, 200, 500, etc.
ほとんどの現代通貨システムは、1,2,5パターンに従う金種を持っています：1、2、5、10、20、50、100、200、500など。

This pattern is also recommended for fixed denomination assets on Byteball.
このパターンは、Byteballの固定資産にもおすすめです。

The coins are initially grouped into packs, similar to packs of paper banknotes.
コインは、紙幣のパックと同様に、パックに最初にグループ分けされる。

The packs can be split into smaller subpacks or individual coins, but not re-merged.
パックは、小さなサブパックまたは個々のコインに分割できますが、再統合はできません。

This means that each transfer must have exactly one input (because merging is disallowed), and output amounts must be multiples of the coin denomination (because the denomination is the smallest indivisible amount).
これは、各転送には正確に1つの入力がなければならないことを意味し（併合が許可されていないため）、出力金額はコイン金種の倍数でなければなりません（金種は最小の分割不可能な金額です）。

Each transaction, issue or transfer, deals with coins of only one denomination.
各取引、発行または譲渡は、1つの金種のみのコインを扱う。

It cannot issue or transfer coins of different denominations at the same time (but each storage unit can include multiple such transactions).
同時に異なる金種のコインを発行したり譲渡したりすることはできません（ただし、各保管単位には複数の取引が含まれている可能性があります）。

A fixed denominations transaction has almost the same format as a transaction with arbitrary-amounts assets, the difference being that only one input is allowed, the amounts must be multiples of one of the denominations, and a denomination field is added:
固定金額取引は、任意の金額の資産を持つ取引とほぼ同じ形式です。差異は1つの入力のみが許可され、額は金種の1つの倍数でなければならず、金種フィールドが追加されます。

payload: {
    asset: "hash of unit where the asset was defined",
    denomination: 100,
    inputs: [ // exactly one input
        {
            type: "issue",
            amount: 1000000,
            serial_number: 1, // always 1 for capped assets
            address: "ISSUER ADDRESS" // only when multi-authored
        }
    ],
    outputs: [
        {
            address: "BENEFICIARY ADDRESS",
            amount: 800 // multiple of 100
        },
        {
            address: "CHANGE ADDRESS",
            amount: 999200 // multiple of 100
        }
    ]
}

If the asset is capped, the entire supply of each denomination must be issued within a single transaction.
資産に上限が設定されている場合、各金種の供給はすべて1回の取引で発行する必要があります。

Thus, if the asset has e.g. 16 denominations, it’ll take 16 transactions to fully issue the asset. If the asset is not capped, the serial numbers of different issues of the same denomination by the same address must be unique.
従って、その資産が、例えば、 16銘柄では、資産を完全に発行するために16回の取引が必要になります。アセットに上限が設定されていない場合は、同じ住所で同じ金種の異なる号の通し番号が一意である必要があります。

If several coins need to be issued or transferred (which is usually the case), the payer includes several such messages in the same unit.
複数のコインを発行または移転する必要がある場合（通常はそうである）、支払人は、同じユニットにいくつかのそのようなメッセージを含める。

For transfers, the coin is identified by the unit, message index, and output index where it was previously transferred to the current owner.
移転の場合、コインは、それが以前に現在の所有者に移転されたユニット、メッセージインデックス、および出力インデックスによって識別されます。

For private payments, the payload goes separately and additionally hides the recipients of all outputs except the one that is meant for the payee:
プライベートペイメントの場合、ペイロードは個別に移動し、受取人を意味するもの以外のすべての出力の受取人を追加で隠します。

payload: {
    asset: "hash of unit where the asset was defined",
    denomination: 200,
    inputs: [{
        unit: "hash of source unit",
        message_index: 2,
        output_index: 0
    }],
    outputs: [
        {
            output_hash: "hash of hidden part of output that
            includes address and blinding factor",
            amount: 800
        },
        …
    ]
}

The information that is open in the outputs allows the recipient to verify that the sum of all outputs does match the input.
出力で開いている情報は、受信者がすべての出力の合計が入力と一致するかどうかを検証することを可能にします。

The single output that is meant for the payee is revealed to him as follows:
受取人のためのものである単一の出力は、次のように彼に明らかになる。

output: {
    address: "BENEFICIARY ADDRESS",
    blinding: "some random string"
}

This enables the payee to verify the output_hash as well as construct the future spend proof when he decides to spend the output.
これにより、受取人はoutput_hashを検証するだけでなく、出力を費やすことを決定したときに将来の支出証明書を構築することができます。

In Byteball, we have a private fixed denominations asset blackbytes that is defined by these properties:
Byteballには、以下のプロパティで定義される私的固定資産金額ブラックバイトがあります。

{
    cap: 2,111,100,000,000,000,
    is_private: true,
    is_transferrable: true,
    auto_destroy: false,
    fixed_denominations: true,
    issued_by_definer_only: true,
    cosigned_by_definer: false,
    spender_name_attested: false,
    denominations: [
        {denomination: 1, count_coins: 10,000,000,000},
        {denomination: 2, count_coins: 20,000,000,000},
        {denomination: 5, count_coins: 10,000,000,000},
        {denomination: 10, count_coins: 10,000,000,000},
        {denomination: 20, count_coins: 20,000,000,000},
        {denomination: 50, count_coins: 10,000,000,000},
        {denomination: 100, count_coins: 10,000,000,000},
        {denomination: 200, count_coins: 20,000,000,000},
        {denomination: 500, count_coins: 10,000,000,000},
        {denomination: 1000, count_coins: 10,000,000,000},
        {denomination: 2000, count_coins: 20,000,000,000},
        {denomination: 5000, count_coins: 10,000,000,000},
        {denomination: 10000, count_coins: 10,000,000,000},
        {denomination: 20000, count_coins: 20,000,000,000},
        {denomination: 50000, count_coins: 10,000,000,000},
        {denomination: 100000, count_coins: 10,000,000,000}
    ]
}

Note that we have double the number of 2-denomination coins because we need them more often.
2銭硬貨の数は2倍に増えているので注意が必要です。

For example we need two 2s for amounts 4 (2+2) and 9 (5+2+2).
例えば、4（2 + 2）と9（5 + 2 + 2）の量に対して2つの2が必要です。

Spend proofs for transfers and issues of private indivisible (fixed denominations) assets are exactly the same as for arbitrary-amounts assets, except that for issues the denomination is not necessarily 1.
民間の分割不可能な（固定金額）資産の移転および発行の証拠を出すことは、金額が必ずしも1ではないことを除いて、任意の金額の資産とまったく同じです。

Unlike divisible payments, each fixed denomination coin is never merged with other coins.
分割可能な支払いとは異なり、各固定金種硬貨は決して他の硬貨とマージされません。

Therefore when the coin is transferred privately, its history grows linearly with time rather than exponentially, and remains manageable (given that computing resources such as storage, bandwidth, and CPU power continue growing exponentially for the foreseeable future).
したがって、コインが私的に移転されると、その歴史は指数関数的ではなく時間とともに直線的に増加し、管理可能なままである（ストレージ、帯域幅、CPUパワーなどのコンピューティングリソースは、近い将来、指数関数的に増加し続けていることが前提です）。

As the history grows, so does the exposure of private payloads to third parties who are future owners of the same coin.
歴史が成長するにつれて、同じ硬貨の将来の所有者である第三者へのプライベートペイロードの公開も同様に行われます。

As discussed previously, the growth is rather slow, and the value of private payloads to adversaries arguably decreases with time.
以前に議論したように、成長はむしろ遅く、敵対者へのプライベート・ペイロードの価値は間違いなく時間とともに減少しています。

However, one should remember that large merchants and exchanges who send and receive many payments every day will probably accumulate very large (but still fragmented) histories.
しかし、毎日多くの支払いを送ったり受け取ったりする大規模な商人や取引所は、おそらくは非常に大きな（しかし断片化した）履歴を蓄積するであろうことを覚えておく必要があります。

One should hence still avoid address reuse, even for private payments.
したがって、プライベートな支払いの場合でもアドレスの再利用は避けなければなりません。

Note that in some cases third parties can infer important information even from private payments.
場合によっては、第三者が私的支払いからでも重要な情報を推測できることに注意してください。

For example, after most packs are already split into individual coins, when a user sends a large number of private payment messages in the same unit, an observer might argue that the user is sending coins of maximum denomination because to send an amount that is significantly larger than the maximum denomination, one would probably send multiple maximum denomination coins.
例えば、ほとんどのパックが既に個々のコインに分割された後、ユーザが同じユニット内に多数のプライベート支払いメッセージを送信すると、観察者は、最大金額のコインを送信していると主張するかもしれない最大金額よりも大きい場合、おそらく複数の最大金種の硬貨を送るだろう。

From this, the observer might infer the approximate amount of the transfer (but nothing more).
このことから、観察者はおおよその移動量を推測するかもしれない。

To avoid leaking such information, it is recommended to spread large amounts across multiple addresses and to send them in separate units.
そのような情報が漏れないようにするには、大量を複数のアドレスに分散し、別々の単位で送信することをお勧めします。

The spend proof approach that we have chosen is not the only one possible.
私たちが選択した費用効果のあるアプローチは、可能なものだけではありません。

To prove to the recipient that the money he receives has not been spent before, the payer could just send him all the private payloads ever sent from his address.
受取人に、彼が受け取ったお金が以前に費やされていないことを証明するために、支払人は自分の住所から送られたすべての私的なペイロードを彼に送ることができる。

The payee could then check each one and verify that there are no double-spends.
受取人はそれぞれを確認し、二重支出がないことを確認することができます。

We chose not to go this way because it involves unnecessary privacy leakage and adds complexity to the light client code.
私たちは不要なプライバシー漏洩を伴い軽いクライアントコードを複雑にするため、このようにしないことを選択しました。

Instead, we chose to somewhat increase space usage but make the verification simpler.
代わりに、スペース使用量をいくらか増やすことを選択しましたが、検証は簡単になりました。

27. Texts

1. テキスト

One can store arbitrary texts using ‘text’ message type:
text'メッセージタイプを使用して任意のテキストを格納することができます：

unit: {
    …
    messages: [
        …
        {
            app: "text",
            payload_location: "inline",
            payload_hash: "hash of payload",
            payload: "any text"
        },
        …
    ],
    …
}

The interpretation of the text is up to the author and his intended audience; Byteball nodes don’t validate it except to check that it is a string.
テキストの解釈は著者と彼の意図する聴衆に任されている。 Byteballノードは、文字列であることを確認する以外は検証しません。

One could use this message type, for example, to send inerasable tweets.
このメッセージタイプを使用して、たとえば、忘れられないつぶやきを送信することができます。

The payload may be private, and it can be useful, for example, for storing hashes of users’ intellectual property or for storing hashes of contract texts that only a few parties need to know.
ペイロードはプライベートであってもよく、例えば、ユーザの知的財産のハッシュを格納したり、いくつかの当事者が知る必要がある契約テキストのハッシュを格納するのに役立ちます。

28. Arbitrary structured data

1. 任意の構造化データ

One can store arbitrary structured data using ‘data’ message type:
「データ」メッセージタイプを使用して任意の構造化データを格納することができます。

unit: {
    …
    messages: [
        …
        {
            app: "data",
            payload_location: "inline",
            payload_hash: "hash of payload",
            payload: {
                key: "value",
                another_key: {
                    subkey: "other value",
                    another_subkey: 232
                }
            }
        },
        …
    ],
    …
}

The interpretation of this data is up to the author and his partners that need to see the data, Byteball nodes don’t validate it except to check that it is an object.
このデータの解釈は、データを表示する必要がある作成者とそのパートナーの責任です.Byteballノードは、オブジェクトであることを確認する以外は検証しません。

For example, this message type can be used to post Ethereum code for the subset of nodes who understand it, but remember that they cannot reject the unit even if the code is invalid by Ethereum rules.
例えば、このメッセージタイプは、それを理解しているノードのサブセットのためにEthereumコードを投稿するのに使用できますが、Ethereumルールによってコードが無効であってもユニットを拒否することはできません。

Like ‘payment’ and ‘text’, ‘data’ messages can be private, in which case only its hash is stored.
「支払い」や「テキスト」と同様に、「データ」メッセージはプライベートにすることができます。この場合、ハッシュのみが格納されます。

Continuing our Ethereum example, Ethereum contracts can be run privately if the corresponding spend proofs are also devised where necessary.
Ethereumの例を続けると、Ethereum契約は、必要な場合に対応する支出証明書も考案されれば、私的に実行することができます。

29. Voting

1. 投票

Anyone can set up a poll by sending a message with app=’poll’:
誰でもapp = 'poll'というメッセージを送信することで、投票を設定できます。

unit: {
    …
    messages: [
        …
        {
            app: "poll",
            payload_location: "inline",
            payload_hash: "hash of payload",
            payload: {
                question: "Should the United Kingdom remain a
                member of the European Union or leave the
                European Union?",
                choices: ["Leave", "Remain"]
            }
        },
        …
    ],
    …
}

To cast votes, users send ‘vote’ messages:
投票を行うために、ユーザーは「投票」メッセージを送信します：

unit: {
    …
    messages: [
        …
        {
            app: "vote",
            payload_location: "inline",
            payload_hash: "hash of payload",
            payload: {
                unit: "hash of the unit where the poll was
                defined",
                choice: "Leave"
            }
        },
        …
    ],
    …
}

Determining which votes qualify is up to the organizer of the poll. Byteball doesn’t enforce anything except the stipulation that the choices are within the allowed set.
投票の対象となる投票を決定するのは、投票の主催者に任されます。 Byteballは、選択肢が許可されたセット内にあるという規定を除いて何も強制しません。

For example, the organizer might accept only votes from attested users or votes from a predetermined whitelist of users.
例えば、オーガナイザーは、認証されたユーザーからの投票のみを受け入れることができ、または所定のホワイトリストのユーザーからの投票を受け入れることができる。

Unqualified votes would hence still be recorded, but should be excluded by the organizer when he counts the votes.
したがって、資格を持たない投票は記録されますが、主催者は投票をカウントする際に除外すべきです。

Weighting the votes and interpreting results is also up to the organizer of the poll.
投票の重み付けと結果の解釈は、投票の主催者に任されます。

If users vote by their balances, one should remember that they can move the balance to another address and vote again.
ユーザーが残高で投票する場合、残高を別の住所に移動して再度投票できることを覚えておく必要があります。

Such votes should be handled properly.
そのような投票は適切に処理されるべきである。

30. Private messaging

1. プライベートメッセージング

For private payments to work, users need a way to securely deliver private payloads to each other.
プライベートペイロードを有効にするには、プライベートペイロードを安全に配信する方法が必要です。

Users, or rather their devices, also need to communicate to assemble signatures for multi-sig addresses.
ユーザまたはそのデバイスは、マルチシグナリングアドレスのシグネチャを組み立てるために通信する必要もあります。

Since we cannot expect user devices to be constantly online and easily reachable (most of them will be behind NAT), we need a store-and-forward intermediary that is always online, easily reachable, and able to temporarily store any data addressed to a user device.
ユーザーの端末は常にオンラインで簡単にアクセスできるとは期待できません（ほとんどがNATの背後にあります）。
常にオンラインで、簡単にアクセス可能で、ユーザデバイス宛てのデータを一時的に保存できるストアアンドフォワード仲介が必要です。

In Byteball, such an intermediary is called the hub, and its operation is similar to email.
Byteballでは、そのような仲介者はハブと呼ばれ、その操作は電子メールに似ています。

A hub is a Byteball node that additionally offers a service of storing and forwarding private messages to connected devices.
ハブは、接続されたデバイスにプライベートメッセージを格納し転送するサービスを提供するByteballノードです。

There can be many hubs.
多くのハブが存在する可能性があります。

Each device that runs a wallet code subscribes to a hub of its choice, and can be reached via this hub (the home hub).
Walletコードを実行する各デバイスは、選択したハブにサブスクライブし、このハブ（ホーム・ハブ）を介してアクセスできます。

The choice of home hub can be changed at any time.
ホームハブの選択はいつでも変更できます。

Each device has a permanent private key that is unique to the device.
各デバイスには、デバイスに固有の永久秘密キーがあります。

The hash of the corresponding public key (more precisely, the hash of the single-sig definition based on this public key) is called the device address, and it is written in base32 like the payment addresses.
対応する公開鍵のハッシュ（より正確には、この公開鍵に基づく単一のsig定義のハッシュ）は、デバイスアドレスと呼ばれ、支払いアドレスのようにbase32で書かれています。

The full device address, including its current hub, can be written as [e-mail].
現在のハブを含む完全なデバイスアドレスは、[e-mail]と書くことができます。

If the device moves to another hub, the part of its full address before @ stays the same.
デバイスが別のハブに移動すると、@の前の完全なアドレスの部分は同じままです。

Unlike email, the name cannot be already “taken”.
電子メールとは異なり、名前はすでに「取得」されていない可能性があります。

Every device connects to its home hub using websockets.
すべてのデバイスは、WebSocketを使用してホームハブに接続します。

The hub sends the new messages to the device and the device stays connected to the hub, so that if a new message arrives while the device is connected the new message is delivered immediately.
ハブは新しいメッセージをデバイスに送信し、デバイスはハブに接続したままであるため、デバイスが接続されている間に新しいメッセージが到着した場合、新しいメッセージがすぐに配信されます。

The hub doesn’t keep copies of the messages that were successfully accepted by the device.
ハブは、デバイスによって正常に受け入れられたメッセージのコピーを保持しません。

The connection to the hub is TLS encrypted.
ハブへの接続はTLSで暗号化されています。

When a device wants to send something to another device, it connects to the recipient’s hub and sends the message.
デバイスが別のデバイスに何かを送信したい場合、デバイスは受信者のハブに接続してメッセージを送信します。

Unlike email, there is no relay – the sender connects directly to the recipient’s hub.
電子メールとは異なり、リレーはありません。送信者は受信者のハブに直接接続します。

All communication between devices is end-to-end encrypted and digitally signed so that even the hub (who is the only man in the middle) cannot see or modify it.
デバイス間のすべての通信はエンドツーエンドで暗号化され、デジタル署名されているので、ハブ（中央の唯一の人）であってもそれを表示または変更できません。

We use ECDSA for signing and ECDH+AES for encryption.
ECDSAは署名に、ECDH + AESは暗号化に使用します。

Before exchanging encrypted messages the devices must be paired, i.e. learn each other’s public key.
暗号化されたメッセージを交換する前に、デバイスは対になっていなければなりません。つまり、互いの公開鍵を学習する必要があります。

This can happen in various ways, e.g. by scanning a QR code that encodes the public key and hub domain name of one of the devices, by sending this information over email, or by clicking a byteball:// link on a secure website.
これは様々な方法で起こりうる。デバイスの公開鍵とハブドメイン名をエンコードするQRコードをスキャンするか、電子メールでこの情報を送信するか、セキュアなウェブサイト上のbyteball：//リンクをクリックします。

For forward security, every device generates a temporary private key and uploads the corresponding public key to its home hub.
フォワードセキュリティのために、すべてのデバイスは一時的な秘密鍵を生成し、対応する公開鍵をホームハブにアップロードします。

Afterwards, the device rotates the key from time to time but keeps a copy of the previous key in case someone sent a message to the previous key while the hub was replacing it.
その後、デバイスはキーを時々回転させますが、ハブがそれを置き換えている間に誰かが前のキーにメッセージを送信した場合に備えて、前のキーのコピーを保持します。

The hub keeps only one version of the temporary public key per subscribed device.
ハブは、サブスクライブされたデバイスごとに1つのバージョンの一時公開鍵のみを保持します。

The sending device follows these steps to send a message:
送信側デバイスは、以下の手順に従ってメッセージを送信します。

1. connects to the recipient’s hub;
2. receives the current temporary public key of the recipient from the hub;
3. generates its own one-time ephemeral key pair;
4. derives ECDH shared secret from the recipient’s temporary public key and own ephemeral private key;
5. AES-encrypts the message using this shared secret;
6. adds its own ephemeral public key;
7. signs the package with its own permanent key; and
8. sends it to the hub.

1.受信者のハブに接続します。
2.ハブから受信者の現在の一時公開鍵を受信する。
3.独自の1回限りの一時鍵ペアを生成する。
4.受信者の一時公開鍵と一時的な秘密鍵からECDH共有秘密を導出する。
5.AES-この共有秘密情報を使用してメッセージを暗号化します。
6.自身の短期公開鍵を追加する。
7.パッケージに独自の永続キーを付ける。そして
8.それをハブに送ります。

The recipient device verifies the signature, derives ECDH secret using the peer’s ephemeral public key and own temporary private key, and decrypts the message.
受信側装置は、署名を検証し、ピアの短期公開鍵および自身の一時的秘密鍵を使用してECDH秘密を派生させ、メッセージを復号化する。

If the sending device fails to connect to the recipient’s hub, it encrypts the message to the recipient’s permanent key (this encryption is not forward secure since it uses a permanent key) and stores the encrypted message locally for future retries.
送信側デバイスが受信者のハブに接続できない場合、受信者の永続キー（この暗号化は永続キーを使用しているため転送が安全ではないため）に暗号化され、暗号化されたメッセージが今後の再試行のためにローカルに格納されます。

The purpose of this encryption is to avoid having unencrypted messages lying around.
この暗号化の目的は、暗号化されていないメッセージが存在しないようにすることです。

After connection to the recipient’s hub succeeds, the device sends this encrypted message, thus encrypting it again (this time, with forward security), so the message is double-encrypted.
受信者のハブへの接続が成功すると、デバイスはこの暗号化されたメッセージを送信し、再度暗号化します（今度はフォワードセキュリティを使用）ので、メッセージは二重暗号化されます。

Note that this is not because single encryption is insufficient, but because we don’t want to store unencrypted content for an indefinite time while the connections are retried.
これは、単一の暗号化では不十分ですが、接続が再試行されている間に暗号化されていないコンテンツを無期限に保存しないためではありません。

Note that the communication is among devices, not users.
通信はユーザーではなくデバイス間で行われることに注意してください。

Users may (and are recommended to) hold several devices, such as a laptop, a smartphone, and a tablet, and set up multisig addresses with redundancy (such as 2-of-3) that depend on keys stored on multiple devices.
ラップトップ、スマートフォン、タブレットなどの複数のデバイスを持ち、複数のデバイスに格納されたキーに依存する冗長性（2の3など）を持つマルチサインアドレスを設定できます（推奨）。

When a user needs to sign a transaction, he initiates it on one of his devices.
ユーザがトランザクションに署名する必要がある場合、ユーザは自分のデバイスの1つでトランザクションを開始する。

This device then sends the partially signed transaction to the other devices using private messages, collects all the signatures, and publishes the transaction.
このデバイスは、部分的に署名されたトランザクションをプライベートメッセージを使用して他のデバイスに送信し、すべての署名を収集し、トランザクションをパブリッシュします。

The private keys stored on each device should never leave that device.
各デバイスに格納されている秘密鍵は、そのデバイスから離れるべきではありません。

When the user replaces one of his devices in a 2-of-3 address, he just uses the other 2 devices to change the address definition and replace the key of the old device with the key of a new device.
ユーザーが3の2/3アドレスでデバイスの1つを置き換えると、彼はアドレス定義を変更して古いデバイスのキーを新しいデバイスのキーに置き換えるために他の2つのデバイスを使用するだけです。

The private messages can also be used for encrypted texting between devices.
秘密のメッセージは、デバイス間の暗号化されたメッセージの送信にも使用できます。

These messages are strictly peer-to-peer, never go into the Byteball database, and can be safely discarded after they are read.
これらのメッセージは厳密にピアツーピアであり、決してByteballデータベースには入らず、読み取り後に安全に破棄することができます。

When users pay in blackbytes or other private assets, they have to send private payloads and absolutely need devices that can communicate.
ユーザーがブラックバイトまたはその他のプライベートアセットで支払いを行う場合、プライベートペイロードを送信し、通信できるデバイスが絶対に必要です。

They need to know each other’s device addresses before they even learn each other’s payment addresses.
彼らはお互いの支払いアドレスを知る前にお互いのデバイスアドレスを知る必要があります。

Once their devices have established communication, the payee can send his payment address to the payer via chat message.
デバイスが通信を確立すると、受取人はチャットメッセージを介して支払い先に支払先住所を送ることができる。

Such a payment scenario also makes it easy to generate a unique payment address for every incoming payment.
このような支払いシナリオはまた、入金支払いごとに一意の支払アドレスを生成することを容易にする。

A merchant can run a chat bot that communicates with users via text messages.
マーチャントは、テキストメッセージを使用してユーザーと通信するチャットボットを実行できます。

When the user is ready to pay the bot generates a new payment address and sends it to the user in a chat message.
ユーザーが支払い準備ができたら、ボットは新しい支払いアドレスを生成し、チャットメッセージでユーザーに送信します。

31. Conclusion

1. 結論

We have proposed a system for decentralized immutable storage of arbitrary data, including data of social value such as money.
我々は、金銭などの社会的価値のデータを含む、任意のデータの分散型不変記憶のためのシステムを提案した。

Every new unit of data implicitly confirms the existence of all previous units.
新しいデータ単位ごとに、以前のすべての単位の存在が暗黙的に確認されます。

Revision of past records similar to that in 1984 becomes impossible, as every new unit also implicitly protects all previous units from modification and removal.
すべての新しいユニットが暗黙のうちにすべての以前のユニットを修正および削除から保護するので、1984年のものに似た過去の記録の改訂は不可能になる。

There is an internal currency that is used to pay for inclusion of data in the decentralized database.
分散データベースにデータを含めるための支払いに使用される内部通貨があります。

The payment is equal to the size of the data to be stored, and other than this payment there are no restrictions on access to the database.
支払いは保管されるデータのサイズと同じであり、この支払以外にはデータベースへのアクセスに制限はありません。

Other assets can also be issued and their ownership can be tracked on the database.
他の資産も発行することができ、その所有権はデータベース上で追跡することができます。

When tracking payments in the internal currency and other assets, double-spends are resolved by choosing the version of history that was witnessed by known reputable users.
内部通貨やその他の資産の支払いを追跡する場合、二重支出は、知られている評判の高いユーザーが目撃した履歴のバージョンを選択することで解決されます。

Settlement finality is deterministic.
決済の最終段階は確定的です。

Assets can be issued with any rules that govern their transferability, allowing regulated institutions to issue assets that meet regulatory requirements.
資産は、譲渡可能性を支配する規則で発行することができ、規制機関は規制要件を満たす資産を発行することができます。

At the same time, transfers can be hidden from third parties by sending their content privately, directly from payer to payee, and publishing spend proofs to ensure that each coin is spent only once.
同時に、コンテンツを非公開に、支払人から受取人に直接送信することで、第三者からの転送を隠すことができます。公開すると、各コインが1回だけ使用されることを保証するための証明書が発行されます。

References

1. Quoted from Wikipedia https://en.wikipedia.org/wiki/Nineteen_EightyFour.
2. Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System, https://bitcoin.org/bitcoin.pdf, 2008.
3. Sergio Demian Lerner. DagCoin, https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf, 2015.
4. Serguei Popov. The Tangle, http://iotatoken.com/IOTA_Whitepaper.pdf, 2016.
5. TomHolden. Transaction-Directed Acyclic Graphs, https://bitcointalk.org/index.php?topic=1504649.0, 2016.
6. Linked timestamping, https://en.wikipedia.org/wiki/Linked_timestamping.
7. Atomic cross-chain trading, https://en.bitcoin.it/wiki/Atomic_crosschain_trading.
8. https://github.com/bitcoin/bitcoin
9. Gavin Wood. Ethereum: A Secure Decentralised Generalised Transaction Ledger, http://gavwood.com/Paper.pdf.