寄付窓口はこちら

Mixin Network ホワイトペーパー翻訳

国内に利用事例があり、調査のために翻訳しました。せっかくなので公開します。

Mixinのホワイトペーパーです。

パブリックな分散台帳で、他のブロックチェーンの資産を取り扱う(サイドチェーンのようでありながら、接続するのは特定のブロックチェーンに限らない)ことができ、PoSで、手数料無く、高速に取引することを実現するコンセプトのようです。

Draft @ July 01, 2018 (2018年7月のドラフト)

Mixin Network

A free and lightning fast peer-to-peer transactional network for digital assets.

デジタル・アセットのための、無料で稲妻のように早いP2P取引のネットワーク。

目次

    1. Motivation 動機
    1. Overview 概要
    1. Mixin Kernel Mixinのカーネル
    2. 3.1 Ghost Output
    3. 3.2 Asynchronous BFT Graph
    4. 3.3 Punitive PoS
    5. 3.4 Trusted Execution Environment
    6. 3.5 Light Witness
    1. Mixin Domain
    2. 4.1 Kernel System Calls
    3. 4.2 Standard Domain Interfaces
    4. 4.3 Domain Extensions
    1. Attack Resistance 攻撃耐性
    1. Governance ガバナンス
    1. XIN - The Token XINトーク
    1. Conclusion まとめ

Motivation 動機

Bitcoin started a new era for financial resources management.

ビットコインは、金融資源にとって新しい時代を開始しました。

People have regained the power to manage their assets by themselves, to monitor how the resources are being distributed, and to rescue the economy from the control of the few.

人々は、自身で資産を管理し、どのように資源が分配されているか監視し、経済を少数の人々の支配から救い出す力を取り戻しました。

Today, both professionals and the general public have accepted the idea behind Bitcoin and blockchain technology, and the user base of crypto currency is growing at a faster and faster pace.

今日では、専門家も一般大衆もBitcoinブロックチェーン技術の背景にある理念を認め、暗号通貨のユーザーベースはますます早い速度で成長している。

Unfortunately, Bitcoin suffers from this fast growing adoption.

残念ながら、Bitcoinはこの急拡大に苦しめられている。

The most significant problems are insufficient transaction capacity, slow confirmation and high transaction fees.

最も大きな問題はトランザクション許容量の不足、遅い承認、高いトランザクション手数料だ。

Due to the inflexible highly distributed nature of Bitcoin network, it’s impossible to fix some critical flaws.

ビットコインネットワークの柔軟性のない高度に分散した性質のために、いくつかの致命的な欠陥を修正することは不可能である。

Rather than fix the original Bitcoin project, most people attempt to invent new projects that address different perceived shortcomings of Bitcoin.

オリジナルのBitcoinプロジェクトを修正するよりも、多くの人々は異なる知られたBitcoinの欠点に対処する新しいプロジェクトを発明している。

Thus Ethereum, Monero, Stellar, Cardano and many new blockchains have been invented in the past few years.

そうして過去数年間の間に、Ethereum、Monero、Stellar、Cardano、そして多くの新しいブロックチェーンが発明された。

Almost all of them attempt to fix the problems of Bitcoin while adding some new features of their own.

それらのほとんどすべてが、独自の新しい機能を追加することで、ビットコインの問題を修正することを試みている。

However, they are unable to rescue or augment the original Bitcoin network, and are neither able to interoperate with each other.

ただし、それらはオリジナルのビットコインを救済、あるいは補強できておらず、また互いに相互運用することもできない。

Fortunately, some Bitcoin believers are working on addressing Bitcoin’s shortcomings, and they have proposed several excellent solutions.

幸いなことに、何人かのビットコイン信奉者はビットコインの欠点の解決に取り組み、彼らはいくつかの優れた解決策を提案しました。

The most significant one is Lighting Network[0], which is a micropayment system built on Bitcoin network without requiring any modifications to Bitcoin code.

最も重要なものの一つは、ビットコインのコードに変更を必要とせずにビットコインネットワーク上に築くマイクロペイメントシステムのLightning Network[0]です。

  1. Lighting Network https://lightning.network

Another interesting solution is the Liquid[1] project from Blockstream, which is a federated and two-way pegged sidechain alongside Bitcoin blockchain.

もう一つ興味深い解決策はBlockstreamのLiquid[1]です。これはBitcoinブロックチェーンと連携し双方向にペグされたビットコインのサイドチェーンです。

  1. Blockstream Liquid https://blockstream.com/liquid

All these attempts have put forward the entire Bitcoin network without sacrificing the security and distributed nature of the original Bitcoin vision.

これらすべての試みは、オリジナルのビットコインのビジョンにおけるセキュリティと分散された性質を犠牲にすることなく、Bitcoinネットワーク全体を前進させます。

Similar solutions have been put forward on Bitcoin competitors, e.g. the Raiden Network[2] on Ethereum.

例えばEthereumにおけるRaiden Network[2]のように、同様の解決策がBitcoinの競合に提案されている。

  1. Raiden Network https://raiden.network

In this paper, we try to propose a solution that can empower all the popular distributed ledgers.

本稿では、すべてのポピュラーな分散台帳を強化できる解決策を提案します。

We call this solution Mixin.

私達はこのソリューションをMixinと呼んでいます。

Mixin is not about creating yet another crypto currency or a competitor to any distributed ledgers.

Mixinはまた別の暗号通貨やいずれかの分散台帳の競合を生み出すようなものではありません。

Similar to what Lighting Network and Liquid are for the Bitcoin blockchain, Mixin is a public distributed ledger to allow any public distributed ledgers to gain trillions of TPS, sub second final confirmation, zero transaction fee, enhanced privacy and unlimited extensibility.

Lightning Network や LiquidがBitcoinブロックチェーンにとって何であるかというのと同じように、Mixinは、パブリック型分散台帳に、何兆ものTPS、1秒以内の最終確認、取引手数料なし、プライバシーの強化と無制限の拡張性を可能にします。

Overview 概要

Mixin is composed of a single theoretically permanent Kernel, many dynamic Domains and different multipurpose Domain Extensions, to formulate an extended star topology.

Mixinは、単一の理論的に永続するカーネル、たくさんのダイナミックなドメインと異なる多目的ドメインエクステンションで構成され、拡張されたスター型トポロジーを組織する。

This topology may lead to the concern that Mixin is a centrally controlled network, but that’s not the case because of how the Kernel itself works.

このトポロジーはMixinが中央で管理されたネットワークだという懸念に導くかもしれないが、カーネル自体の動作原理のために、そうではない。

Mixin Kernel is a high performance distributed ledger and its sole responsibility is to verify asset transactions.

Mixinカーネルは高性能な分散台帳であり、その唯一の責任は資産取引の検証です。

That said, the single permanent Mixin Kernel is also a distributed network just like Bitcoin network as a whole.

つまり、単一の永続Mixinカーネルはまた、全体としてはBitcoinネットワークのように分散したネットワークでもあるということです。

Although Mixin Kernel verifies asset transactions, it doesn’t produce any assets.

Miixnカーネルは資産の取引を検証しますが、資産を生み出すことはありません。

All assets flow through the Kernel by Mixin Domains.

すべての資産の流れはMixinドメインによってカーネルを通ります。

Each Mixin Domain is also a distributed ledger, whose job is providing assets to the Mixin Kernel.

各Mixinドメインはまた分散台帳であり、その仕事はMixinカーネルに資産を提供することです。

The assets may be those on Bitcoin, Ethereum or any other blockchains, or even central organizations like banks.

資産は、Bitcoin、Ethereum、またはその他ブロックチェーン、あるいは銀行のような中央組織の資産です。

While each Mixin Domain is a component to provide assets for Mixin Kernel, the Kernel itself is also a component in the Mixin Domain to verify and govern its assets.

各MixinドメインはMixinカーネルに資産を提供するコンポーネントで、カーネル自体はまた、Mixinドメインの中のアセットの検証と管理を行うコンポーネントです。

Unlike most existing gateway based solutions, Mixin Kernel and Domains are all public available distributed ledgers, with no central authorities.

ほとんどの既存のゲートウェイベースのソリューションと異なり、Mixinカーネルドメインはすべてパブリックに利用可能な分散台帳で、中央権力がない。

From the Kernel to Domains, the Mixin Network is all about assets and transactions.

カーネルからドメインまで、Mixinネットワークはすべて資産と取引に関するものです。

The Mixin Domain Extension is where the magic happens, whether for Ethereum contracts, EOS contracts, a distributed exchange on somewhat trusted instances, or anything else.

Mixinドメインエクステンションは、Ethereumコントラクトか、EOSコントラクトか、何らかの信頼された例における分散化された取引、あるいはその他の目的にかかわらず、魔法が起きる場所です。

Mixin Kernel Mixinカーネル

Ghost Output ゴーストアウトプット

Mixin Kernel utilizes the UTXO model of Bitcoin to handle transactions, and CryptoNote[0] one time key derivation algorithm to improve privacy, since there is no address reuse issue.

Mixinカーネルは、トランザクションを処理するためにBitcoinのUTXOモデルを利用し、プライバシーの改善のためにCryptoNote[0]ワンタイムキー導出アルゴリズムを利用します。アドレス再利用の問題がないためです。

  1. CryptoNote https://cryptonote.org/whitepaper.pdf

We call the one time key a Ghost Address and the output associated with it a Ghost Output.

私達はワンタイムキーをゴーストアドレスと呼び、それに関連するアウトプットをゴーストアウトプットと呼びます。

In the algorithm, each private user key is a pair (a, b) of two different elliptic curve keys, and the public user key is the pair (A, B) of two public elliptic curve keys derived from (a, b).

このアルゴリズムでは、それぞれのプライベートユーザーキーは、2つの異なる楕円曲線鍵である(a, b)のペアであり、パブリックユーザーキーは、(a, b)から導出される2つの公開の楕円曲線鍵のパブリックユーザーキーペア(A, B)です。

When Alice wants to send a payment to Bob, she gets Bob’s public user key (A, B) and derives at least three Ghost Addresses with some random data, which ensures at least three different Ghost Outputs will be created for Bob.

アリスがボブに支払いをしたい時、アリスはボブのパブリックユーザーキー(A, B)を得て、いくつかのランダムデータから少なくとも3つのゴーストアドレスを導出する。それは少なくとも3つの異なるゴーストアウトプットがボブのために生成されることを保証する。

The three Ghost Outputs threshold delivers better privacy, and also forces the outputs random amounts.

3つのゴーストアウトプットのしきい値は、より良いプライバシーを提供し、また、アウトプットをランダムな量にさせる。

After deriving the Ghost Addresses, Alice will sign the transaction with CryptoNote algorithm.

ゴーストアドレスの導出後、アリスはCryptoNoteアルゴリズムトランザクションに署名します。

Note that, to improve privacy, Alice is forced to pick random UTXOs as the transaction inputs.

アリスはトランザクションのインプットとしてランダムなUTXOを選択させられていることに注意してください。

After the transaction is signed, Alice sends it to the Mixin Kernel.

トランザクションが署名されると、アリスはそれをMixinカーネルに送ります。

Only Bob can recognize his transactions due to the Ghost Address feature, he can decrypt the output information with his tracing key (a, B).

ゴーストアドレス機能によってボブだけが彼のトランザクションに気づくことができ、ボブは彼の追跡鍵(a, B)によって出力情報を復号できる。

If an exchange wants to have a transparent address to disclose all its assets information publicly, it can just publish its tracing key (a, B) so that everybody can recognize all its transactions but can’t spend them without the secret key b.

もし取引所が、すべての資産の情報を公に開示するために透明性の高いアドレスを持ちたい場合、追跡鍵(a, B)を公開することでそれは可能である。誰でもすべてのトランザクションを認識できつつも、秘密鍵bなしでそれらが使用されることはない。

Asynchronous BFT Graph

Each Mixin Kernel Node is required to pledge 10,000 XIN, therefore due to the 500,000 XIN circulating supply[0], no more than 50 Kernel Nodes will exist.

Mixinカーネルの各ノードは10,000XINを担保にする必要があります。したがって500,000XINの供給量によって、存在するノードは50以下です。

To prevent extremely centralized authority, the Kernel can only be booted with at least 7 Kernel Nodes.

極端な集権を防ぐため、カーネルは最低でも7つのノード上でしか起動しません。

The Kernel nodes make up a loose mesh topology, and are responsible for transaction validation and persistence.

カーネルのノードは緩やかなメッシュトポロジーを構成し、トランザクションの検証と永続化を担います。

Unlike a blockchain, there are no blocks in the Mixin Kernel, all transactions will be exponentially broadcasted as soon as possible.

ブロックチェーンとは異なり、Mixinカーネルにはブロックは無く、すべてのトランザクションはできる限り早くブロードキャストされます。

A typical Mixin Kernel transaction finalization sequence goes as follows:

典型的なMixinカーネルトランザクションがファイナライズされる順序は以下の通りです:

1.When Alice’s signed transaction is sent to the Mixin Kernel with K (7 <= K < 50) nodes, b (b > 1) random nodes (A) will receive it.

1.アリスがトランザクションに署名しMixinカーネルのK(7<= K <50)個のノードに送られ、b(b>1)個のランダムなノードである(A)がそれを受け取る。

2.Each node does the same transaction validation.

2.それぞれのノードが同じトランザクションの検証を行う

1)Inputs are all unspent. インプットがすべて未使用であること

2)Input and output amounts are in valid range. インプットとアウトプットの量が正しい範囲であること

3)Verify the signature of each input. 各インプットへの署名の検証

4)The total of input amounts equal to the total of outputs. すべてのインプットの合計がアウトプットの合計と等しいこと

3.Each node will create a Kernel Snapshot with the validated transaction, and the snapshot is the base unit stored in the Kernel to construct a DAG. Each snapshot is composed of:

各ノードは検証されたトランザクションを使用してカーネルスナップショットを作成する。スナップショットはDAGを構成するためにカーネルに格納される基本単位である。それぞれのスナップショットは以下から構成される:

1)The transaction as payload. ペイロードとしての取引

2)Previous snapshot hash of this node. そのノードの前のスナップショットのハッシュ

3)The node signature. ノードの署名

4.The signed snapshot will be broadcasted to another b random nodes (B) as soon as possible.

署名されたスナップショットは他のランダムなb個のノード郡(B)に出来るだけ早くブロードキャストされる。

After received the snapshot and validated with the same procedure in step 2, a new snapshot will be created immediately.

スナップショットを受信し、ステップ2どおなじ手順で検証したあと、すぐに新しいスナップショットが作成されます。

This snapshot has the same payload as received snapshot, and the referenced snapshot hash is a pair of previous snapshot hash in this node and the received snapshot hash.

このスナップショットは受信したスナップショットと同じペイロードを持っていて、参照されたスナップショットのハッシュは、このノードの前のスナップショットのハッシュと受信したスナップショットのハッシュのペアである。

5.Steps 4 will be repeated until the node learnt that wether the transaction is approved or rejected by at least 2/3K nodes.

ステップ4は、トランザクションが少なくとも2/3Kのノードによって承認または拒否されたことをノードが認識するまで、各スナップショットごとに繰り返されます。

Since each snapshot referenced the parents up until the nodes group A, it’s easy for new nodes to learn that the previous snapshots are aware of the snapshots.

各スナップショットがノードグループAに至るまで親を参照したことで、新しいノードは前のスナップショットがスナップショットを認識していると知ることは簡単です。(※訳自信なし)

This procedure can avoid lots of redundant works.

この手順で多くの冗長な作業が避けられます。

6.In this procedure, a transaction can be approved or rejected in about K/b2 rounds on average, considering the typical Kernel size, the latency may be within a single second with very high probability and guaranteed within seconds.

この手順では、トランザクションは平均K/b2回で承認または拒否される。典型的なカーネルのサイズを考慮すると、待ち時間はおそらく高い確率で1秒以内であり、数秒以内に保証される。

Due to the asynchronous BFT consensus, double spend is impossible.

非同期のBFT(訳注: Byzantine Fault Tolerance)コンセンサスにより、二重支払いは不可能です。

Because of the UTXO nature, snapshots order is irrelevant and high concurrency can be guaranteed in the DAG.

UTXOの性質により、DAGでは、スナップショットの順番は関係なく高い並列性が保証されます。

Punitive PoS

Each Mixin Kernel node takes 10,000 XIN, which is approximate 2% of the network stake.

各Mixinカーネルノードはネットワークのおよそ2%であるである10,000XINのステークが必要です。

The Kernel can only operate with at least 7 nodes joined, or about 15% of the whole network stake.

カーネルは最低でも7ノードまたはネットワーク全体の15%のステークが必要です。

The Kernel BFT consensus is secured by a strict punitive PoS, if a Kernel Node is determined to be an attacker, all its collateral will be recycled to the mining pool.

カーネルBFTコンセンサスは、厳格な懲罰的PoSによって保護されており、カーネルノードが攻撃者であると判断されれば、そのすべての担保がマイニングプールに再利用されます。

The node will be identified as an attacker if it tried to broadcast an obvious double spend snapshot.

ノードは、明らかな二重支払いのスナップショットをブロードキャストしようとした場合、攻撃者とみなされます。

A snapshot will be considered obvious when some of its inputs state have been validated by at least 2/3K nodes.

スナップショットは、いくつかのインプットの状態が最低でも2/3Kのノードに検証された時、明らかだと考えられます。

The first time a node sends out an attacking snapshot, its stake won’t be recycled, but it will be flagged by the network as a potential attacker.

ノードが最初に攻撃スナップショットを送信した時、ステークはリサイクルされませんが、ネットワークによって潜在的な攻撃者としてフラグが立てられます。

The Kernel size will be temporally reduced to K - 1, with this reduction invisible to the potential attacker.

カーネルのサイズが一時的に K-1 に減り、このことは潜在的な攻撃者にはわかりません。

All other nodes will still broadcast to the flagged node, but won’t consider its snapshots in stake votes.

すべての他のノードはフラグが建てられたノードにブロードキャストを続けますが、ステークの投票には算入しません。

If further snapshots from the flagged node remain malicious, the Kernel will sign a snapshot with a transaction that will transfer all the flagged node’s collateral to the mining pool.

もしさらにフラグが立てられたノードからのスナップショットに悪意があるままであれば、カーネルはフラグが立てられたノードのすべての担保をマイニングプールに移転するトランザクションとともにスナップショットに署名します。

The flagged node will be permanently removed from the Kernel and it will have some period to appeal to Mixin Kernel Governance[0], which is voted by all XIN holders.

フラグが立てられたノードは、カーネルから永久に取り除かれ、XINホルダーによって投票されるMixin カーネルガバナンスに対してアピールするためのいくらかの期間が与えられます。

  1. Section Governance for details

Trusted Execution Environment

Mixin Kernel is already an ABFT consensus DAG.

MixinカーネルはすでにABFTコンセンサスDAGである。

To ensure further security, Kernel nodes must run in Trusted Execution Environment[1].

さらなるセキュリティを確保するために、カーネルノードはTrusted Execution Environment[1]で実行されなければならない。

  1. Trusted Execution Environment https://en.wikipedia.org/wiki/Trusted_execution_environment

Specifically, Mixin uses Intel SGX[2] as the TEE implementation.

具体的には、MixinはIntel SGX[2]をTEEの実装として利用する。

  1. Intel SGX https://software.intel.com/enus/sgx-sdk/details

The TEE enforcement ensures three important security and trust factors in Mixin Kernel.

TEEの実施により、Mixinカーネルでは3つの重要なセキュリティと信頼の要素が保証されます。

1.All Kernel nodes should run the same consensus ruleset.

すべてのカーネルノードは同じコンセンサスルールセットを実行する必要があります。

2.Mixin Kernel will be trusted due to the Intel SGX enclave, even when the Kernel is controlled by several earlier Kernel nodes.

MixinカーネルIntel SGXエンクレーブ(メモリーのプライベート領域)のために、カーネルが初期の数ノードでコントロールされているときでさえ、信頼されます。

3.Distributed Domain communications will be much more secure.[0]

分散化されたドメインのコミュニケーションは遥かに安全になります。

  1. Section Kernel System Calls for details

The underlying logic for the TEE security is that Intel SGX is somewhat trusted for the Mixin system.

TEEセキュリティの基本的なロジックは、Intel SGXがMixinシステムのために信頼されたものであるということだ。

Note that, Mixin Kernel is secure by itself, at least as secure as existing BFT solutions.

Mixinカーネルはそれ自体が、少なくとも既存のBFTソリューションと同じくらい安全であることに留意してください。

The mandatory Intel SGX just makes it better.

Intel SGXを強制することは、それをさらに良くします。

Light Witness

Mixin Light node is a simplified payment verification (SPV) node to Mixin Kernel.

Mixinライトノードは、Mixinカーネルに対する簡易支払い検証(SPV)ノードです。

It typically stores all its unspent outputs for easy account balance query.

それは通常、完結な口座残高照会のために、すべての未使用のアウトプットを保管します。

If the Light node is a XIN holder, it has the chance to act as a Light Witness.

ライトノードがXIN所有者の場合、ライトWitness(証人)として振る舞う機会があります。

The Light Witness will actively monitor the Mixin Kernel, and will be scheduled to vote automatically on the attacker appeals.

ライトWitnessはMixinカーネルを積極的に監視し、攻撃者のアピールに対して自動的に投票することが予定されます。

The Light Witness vote is weighted on their XIN stake.

ライトWitnessの投票は、彼らのXIMのステークによって重み付けされます。

And the vote is mostly on the attacker node’s network connectivity state to determine whether the attacker behavior is caused due to network delay.

攻撃者の振る舞いがネットワークの遅延によって起きたものなのかどうかを判断するために、投票は主に攻撃者のノードのネットワークの接続状態について行われます。

All the Light Witness votes will be weight calculated with the Mixin Kernel Governance votes, to determine the final attacker appeal.

最終的な攻撃者のアピールの判断のためには、すべてのライトWitnessの投票はMixinカーネルのガバナンス投票とともに重み付けされます。

If the appeal fails, the penalty will be final.

アピールが失敗すると、ペナルティが決定します。

The Light Witness is incentivized to do these votes because they could get the mining reward if they do some work for the network itself.

ライトWitnessは、ネットワークのために働くことでマイニング報酬を得られるので、これらの投票を行うようにインセンティブ付けられています。

Mixin Domain

Mixin Domain is a distributed ledger to provide assets for the Mixin Kernel.

MixinドメインはMixinカーネルに資産を提供するための分散台帳です。

The assets may be those on Bitcoin, Ethereum or any other blockchains, even central organizations like banks.

資産は、Bitcoin、Ethereum、その他のブロックチェーン、銀行などの中央の組織の資産でもかまいません。

Kernel System Calls

Mixin Kernel offers some system calls to communicate with Domains, and it’s the only way the Kernel and Domains can exchange state.

Mixinカーネルは、ドメインと通信するためのいくつかのシステムコールを提供しており、それがカーネルドメインが状態を公開する唯一の方法です。

The system calls are defined as standard JSON-RPC interfaces.

システムコールは標準のJSON-RPCインターフェースで定義されています。

JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol.

JSON-RPCはステートレスで軽量なリモートプロシージャコール(RPC)プロトコルです。

It is transport agnostic in that the concepts can be used within the same process, over sockets, over HTTP, or in many various message passing environments.

同じプロセスの中で利用でき、ソケット、HTTP,または多くの様々なメッセージ伝達環境を介して使用できる概念で、トランスポートに依存しません。

It uses JSON (RFC 4627) as data format.

それはJSONRFC 4627)をデータフォーマットとして使用します。

Currently Mixin Kernel only implements the standard HTTPS transport for the protocol, and the available calls are listed below.

現在Mixinカーネルプロトコルとして標準のHTTPS伝送を実装しているだけであり、利用できるコールは以下のものである。

kernel_registerDomain

Register the domain and waiting for the Kernel approval to connect.

ドメインを登録しカーネルが接続を承認するのを待ちます。

The call can also update the domain nodes.

コールはまたドメインのノードを更新できる。

The registered domain will be forced to form a XIN stake based network between the domain nodes and the Kernel as a whole.

登録されたドメインは、ドメインノードとカーネル全体の間で、XINステークベースのネットワークを形成させられる。

The domain registration is a governance behavior, and should relate to the domain nodes XIN stake.

ドメイン登録はガバナンスの動作であり、ドメインのXINステークノードに結びつく必要があります。

In the future, we hope to implement a more automatic domain management policy in Mixin Kernel.

将来的には、より自動化されたドメイン管理策をMixinカーネル内で実装することを望みます。

The upgrade policy should always be governed by all Kernel Nodes and XIN holders.

アップグレード方法は常にすべてのカーネルノードとXINホルダーによって管理されるべきです。

Parameters パラメータ

1.UUID - A unique UUID that represents the domain among all other domains.

1.UUID - 他のすべてのドメインの間でそのドメイン表すユニークなUUID

2.Array - Array of domain nodes’ transparent public keys.

2.Array - ドメインノードの透明な公開鍵の配列

params: [“c6d0c728-2624-429b-8e0d-d9d19b6592fa”,
[“4b7a842ce6050c99450dc30b4e848c4eaffd33915653b472d900f47
d11722058”,
“b3aef7b3a998a593c157103d20f9cb17bdbd535f304b17c862e3b35b
108faeb8”]] 

Returns 返り値

String - Indicate the registration request state, the value is one of invalid, pending, denied, and approved.

String - 登録依頼の状態を表す。値は invalid, pending, denied, approved のいずれか。

Note that, all Kernel System Calls should be forwarded to b known Kernel Nodes to ensure delivery.

すべてのカーネルシステムコールは、伝送を確実にするために、既知のb個のカーネルノードに転送されるべきであることに留意してください。

Standard Domain Interfaces

A domain can only be registered to the Mixin Kernel if it implements all the Standard Domain Interfaces.

ドメインは、それがすべての標準ドメインインターフェースを実装している場合のみ、Mixinカーネルに登録できる。

domain_getKeyDerivationFunction

Get the domain specific asset key derivation function, which is one of some key derivation methods in Mixin Kernel, and could be upgraded with governance.

ドメイン固有の資産の鍵を導出する関数を取得する。Mixinカーネルにおけるいくつかの鍵導出メソッドのうちの一つであり、ガバナンスによってアップグレードできる。

The supported methods may also be extended to some sandboxed VM languages such as solidity.

サポートされているメソッドはSolidityなど、いくつかのサンドボックス化された仮想言語にも拡張し得ます。

Parameters 引数

1.UUID - The global unique asset ID in the whole Mixin Network.

1.UUID - Mixinネットワーク全体でグローバルにユニークなアセットのID

params: [“c6d0c728-2624-429b-8e0d-d9d19b6592fa”]

Returns 返り値

Object - The function name and parameters.

オブジェクト - ファンクション名とパラメータ

1.method: String - The function name, one of the predefined derivation function names in Kernel.

1.method: String - ファンクション名。カーネル内で事前に定義された導出関数のうちの一つ。

2.params: Array - The parameters should be used relative to the method.

2.params: Array - メソッドに関連づいて使用されるべきパラメーター。

domain_associatePublicKey

Associate a Mixin public key to the domain for an asset supported by the domain.

Mixinパブリックキーを、ドメインでサポートされているアセットとして、そのドメインに関連付ける。

The public key and domain asset association is the magic that will associate an external asset to the Mixin Kernel.

公開鍵とドメインアセットの関連は、外部のアセットとMixinカーネルを関連付ける魔法です。

After public key associated with an asset, it will get an asset specific public key, e.g. Bitcoin public key.

パブリックキーがアセットに関連付けられたら、ビットコインのパブリックキーなど、アセット固有のパブリックキーを得ます。

Whenever the Bitcoin blockchain has an output to this public key, the domain will create a transaction to the Mixin public key.

Bitcoinブロックチェーンでこの公開鍵への出力があると、ドメインはMixin公開鍵へのトランザクションを作成します。

This works because the Mixin Kernel and the Mixin Domain is also a Proof of Stake network.

これはMixinカーネルとMixinドメインがまたProof of Stakeネットワークであるため機能します。

Besides the XIN collateral, there are also additional Intel SGX enforcement for all related functions.

XINの担保に加えて、すべての関連するファンクションでIntel SGXの強制もあります。

After the domain create the asset transaction to the public key, the asset will be locked by both the Mixin Kernel and Mixin Domain.

ドメインが公開鍵へのアセットのトランザクションを作成したあと、アセットはMixinカーネルとMixinドメインによってロックされます。

This result in a corresponding asset lightning transaction in Mixin Kernel.

これによって、Mixinカーネルで対応するアセットが高速に取引されます。

Parameters 引数

1.String - The Mixin public key.

1.String - Mixinパブリックキー

2.UUID - Unique asset ID within the whole Mixin Network.

2.UUID - Mixinネットワーク全体の中でユニークなアセットID

params:
[“4b7a842ce6050c99450dc30b4e848c4eaffd33915653b472d900f47d11722058”, “c6d0c728-2624-429b-8e0d-d9d19b6592fa”] 

Returns 返り値

String - The asset specific public key associated with the Mixin public key.

String - Mixinパブリックキーと関連付けられたアセット固有のパブリックキー

domain_unlockAsset

Unlock the asset and transfer out to external sources, this is similar to the withdrawal action on a crypto asset exchange.

資産のロックを解除して外部のソースに移転する。外部暗号資産交換所における引き出しに似たものである。

The operation to unlock is somewhat similar to the associate function, it must be signed by both the Mixin Kernel and Mixin Domain to make it a valid snapshot acceptable by the network.

アンロック処理は domain_associatePublicKey に似ていて、ネットワークによって受け入れられる正しいスナップショットとするために、MixinカーネルとMixinドメインの両方に署名されなければならない。

Parameters 引数

1.UUID - Unique asset ID within the whole Mixin Network.

1.UUID - Mixinネットワーク全体でユニークなアセットのID

2.String - External asset specific public key.

2.String - 外部アセット固有のパブリックキー

3.String - The amount of asset to unlock.

3.String - アンロックするアセットの量

4.String - The fee for external source transaction.

4.String - 外部ソースのトランザクション手数料

params: [“c6d0c728-2624-429b-8e0d-d9d19b6592fa”,“15SdoFCiwaoUN4grnhPCoDWxWLcY6ZT68V”, “12.345678”,“0.0005”] 

Returns 返り値

String - The external sources transaction identifier, e.g. transaction hash.

String - 外部ソースのトランザクションID(トランザクションハッシュなど)

The above three Domain Interfaces are mandatory for all domains to be approved by the Kernel.

以上の3つのドメインインターフェースが、カーネルに承認されるために、すべてのドメインで必須です。

They communicate through the Intel SGX trusted transport layer, and all encrypted private keys are securely duplicated in all Kernel Nodes and Domain Nodes.

Intel SGXの信頼されたトランスポートレイヤーを通してこれらは通信し、すべての暗号化されたプライベートキーは、すべてのカーネルノードとドメインノードに安全に複製される。

Domain Extensions

With a transaction only purpose Mixin Kernel, and Mixin Domains as assets provider and gateway to external blockchains or any other sources, Mixin has become the most sophistic and high performance distributed ledger to almost all digital assets.

トランザクション専用のMixinカーネル、そして、アセットプロバイダーと外部のブロックチェーンやその他リソースとのゲートウェイであるMixinドメインによって、Mixinは最も洗練され、パフォーマンスの高い、ほぼすべてのデジタル・アセットのための分散台帳となる。

However, people need smart contracts, which have been made popular by Ethereum.

しかしながら、人々は、Ethereumによってポピュラーになったスマートコントラクトを必要とする。

We allow Extensions to Mixin Domains, something similar to smart contract but with higher robustness, capability and performance.

私達は、スマートコントラクトに似た、しかしより高い堅牢性、能力、そしてパフォーマンスの、Mixinドメインに対するエクステンションを許可する。

Domain Extensions are programs running in the Domain Virtual Machine secured by the Secure Enclave in Intel SGX, a popular and secure Trusted Execution Environment.

ドメインエクステンションは、一般的で安全である実行環境であるIntel SGXのセキュアエンクレーブによって保護されたドメイン仮想マシンの中で動作するプログラムです。

Due to the possibility to run the “smart contract” in a single computation unit, Domain Extensions can achieve many goals which are almost impossible in something similar to Ethereum.

単一計算ユニットでスマートコントラクトを実行できることにより、ドメインエクステンションはEthereumのようなものではほぼ不可能なたくさんのゴールを達成する可能性がある

1.Much higher performance and lower latency which is only limited by the hardware.

1.ハードウェアによってのみ制限されるとても高い性能と低い遅延

2.Non-deterministic transactions, e.g. trustable random number.

2.信頼できる乱数などの非決定的トランザクション

3.Interact directly with trusted external sources.

3.信頼できる外部ソースとの直接のインタラクション

Besides these trusted applications, it’s also possible to run other popular distributed VM, e.g. Ethereum or EOS.

これらの信頼されたアプリケーションに加え、EthereumやEOSなどの他の一般的な分散型仮想マシンを実行することもできる。

Attack Resistance 攻撃耐性

Due to the PoS and distributed nature of both Kernel and Domain Nodes, and enforcement by Intel SGX, the keys are almost guaranteed to be safe from leaks.

カーネルドメインのノードのPoSと分散型の性質、Intel SGXの強制によって、鍵は漏洩に対して安全であることがほぼ保証されます。

Because of the highly distributed key duplication and secret sharing mechanism, the encrypted private keys are also guaranteed to be safe from loss.

高度に分散化された鍵の複製と秘密共有メカニズムによって、暗号化されたプライベートキーは紛失からも安全であることが保証されています。

Ideally, each asset should have many different distributed domains, these domains are governed by the Kernel and securely enforced by Intel SGX.

理想的には、各アセットは多くの異なる分散化されたドメインを持つべきであり、それらのドメインカーネルに管理され、Intel SGXによって安全に実施されます。

The associated keys can only be accessed from where they were generated in the Domain, further improving the degree of protection.

関連付けられた鍵は作成されたドメインからのみアクセスでき、保護の程度はさらに改善しています。

The Kernel will balance the assets in different Domains constantly to further prevent the asset loss in the event of an almost impossible private key leak or loss in different domains.

カーネルは、異なるドメインにおいてほぼ不可能なプライベートキーの漏洩や喪失発生によるアセットの損失を、さらに防ぐために、定期的に異なるドメインでアセットのバランスを取ります。

We will prove that Mixin is safe for digital assets against different possible attack vectors.

我々はMixinがデジタル・アセットにとって、様々な攻撃の可能性に対して安全であることを証明します。

To simplify the explanation, only Bitcoin will be used as a sample.

説明を簡単にするために、ビットコインを例に使用します。

Key Association

Key association is the first step to grant a Mixin public key with Bitcoin access.

Key Associationは、MixinパブリックキーにBitcoinへのアクセス権限を与える(?)最初のステップです。

Every Mixin public key Mpub will have a Bitcoin public key Bpub associated, how this association occurs and is managed determines the key safety.

それぞれのMixiパブリックキーMpubはビットコインのパブリックキーBpubと関連を持ち、どうやってこの関連が行われ管理されるかは、鍵の安全性を左右します。

Bpub is the public derivation of Bitcoin private key Bpriv, so how Bpriv is generated defines the Bpub correctness.

Bpub は BitcoinプライベートキーBprivの公開の派生物であるから、どのようにBprivが生成されるかがBpubの正しさを定義します。

Bpriv is generated purely by the Mixin Domain itself, and it will transfer part of it to the Kernel to keep it by (t-n)-threshold secret sharing scheme.

Bprivは純粋にMixinドメイン自身によって生成され、その一部はカーネルへ、(t-n)-threshold秘密共有スキームで保持するために、伝達されます。

If the domain is trustable in this procedure, the association is absolutely secure.

この手順においてドメインが信頼できるのであれば、関連付けは絶対的に安全です。

Intel SGX will enforce the domain trustworthiness, and even when Intel SGX itself is not safe, which is almost impossible, the following parts in this paper will prove that the Bitcoin asset will also be secure in Mixin.

Intel SGXはドメインに信頼性を強い、またIntel SGX自身が安全でない場合ですら、とはいえそれはほぼ不可能ですが、以下でBitcoin資産もまたMixinの中で安全であることを証明します。

Deposit Attack

Deposit is the action when external assets flow into Mixin Kernel, this is the first step when some BTC joins Mixin.

デポジットは外部資産がMixinカーネル流入するときのアクションであり、いくらかのBitcoinがMixinに入る最初のステップです。

Since key association is proved secure, and all Mixin Domains are governed by Mixin Kernel, if some BTC successfully submitted to the Kernel, it will be guaranteed to the correct Mpub.

Key associationは安全であることが証明されており、すべてのMixinドメインはMixinカーネルによって管理されているため、いくらかのBitcoinが正常にカーネルに送信された場合は、それは正しいMpubに対して保証されます。

All Bitcoin deposits will also require a large enough domain finality threshold, e.g. there must be at least 12 Bitcoin confirmations before the system accept the asset.

すべてのBitcoinデポジットはまた十分に大きなドメインファイナリティのしきい値も必要です。例えば、システムが資産を受け入れるのに、少なくともBitcoinの12承認が必要です。

In this way the system has enough time to detect fraudulent domain action and will punish it without any Bitcoin loss.

このように、システムは不正なドメインアクションを検出するのに十分な時間を持ち、ビットコインを失うことなく不正を罰します。

The domain mandatory Intel SGX requirements will improve this further.

ドメインIntel SGX必須要件はこれをさらに改善します。

Fraudulent Domain or Key Leak

The Mixin Kernel constantly balances the assets across all Domains according to their behavior and collateral amount.

Mixinカーネルは、すべてのドメインにわたって常に、それらのふるまいと担保の量に応じて資産のバランスを取ります。

If a domain is compromised or hacked, the leaked key will only cause partial Bitcoin loss.

ドメインが危険にさらされたりハッキングされた場合には、漏洩したキーは部分的なビットコインの喪失を起こすだけです。

Also, Intel SGX will prevent fraudulent Domains from existing and keep hackers away in most cases.

また、Intel SGXは不正なドメインが存在することを防ぎ、殆どの場合ハッカーを排除します。

Further more, Kernel and Domains will always load most Bitcoin into a multi signature Bmpub, this is almost impossible get hacked, especially when correctly and transparently distributed.

さらに、カーネルドメインは常に殆どのビットコインをマルチシグBmpubにのせます。特に正しく、そして透明性のある形で分散している場合、これはほとんどハッキングは不可能です。

Damaged Domain or Key Loss

Just like the fraud domain issue, domain damage or key loss will only affect a few Bitcoin assets.

不正なドメインの問題と同様に、ドメインの損傷や鍵の喪失はBitcoin資産だけに影響します。

Since Mixin Governance will ensure the Domain is correctly implemented as a distributed system, it’s almost impossible to have the domain damaged as a whole.

Mixinガバナンスによって分散システムとしてドメインが正しく実装されているようになるため、ドメインは全体として破壊することはほぼ不可能です。

Compare to Exchange

Exchanges or other kinds of central managed Bitcoin solutions typically store most BTC in their cold storage.

取引所またはその他の種類の中央管理されたBitcoinソリューションは通常、BTCを彼らのコールドストレージに保管する。

Cold storage refers to private keys which are never exposed to the Internet and managed by several people in the same firm.

コールドストレージとは、インターネットに公開されたことがなく、同じ企業内の複数の人々によって管理されているプライベートキーのことです。

In terms of security, if both Mixin and Exchanges implement the solutions correctly without any bugs, Mixin should be considered much safer and trustable., because Mixin multi-signature Bmpub is guaranteed to be managed by many different parties that are unknown to each other, while exchanges have their keys kept by their own people who are much more easily capable of colluding.

セキュリティの面では、もしMixinと取引所の両方がバグ無くソリューションを正しく実装した場合、Mixinはよりだいぶ安全で信頼できると考えられる。 なぜなら、取引所は鍵を容易に結託しうる自社の人々で管理するが、MixinマルチシグネチャーBmpubは互いに知らない多くの異なる関係者によって管理されることが保証されている。

Hackers aside, exchanges may have the chance to steal the money by themselves.

ハッカーはさておき、取引所は彼ら自身でお金を盗むチャンスを持っている。

This is much harder or even impossible on Mixin.

Mixinではこれはとても難しいか不可能である。

Further, since exchanges are almost all closed source systems, they often have bugs which are not discovered until a hack occurs.

さらに、交換所はほとんどすべてクローズドソースのシステムなので、かれらにはしばしばハックが発生するまで発見されないバグがあります。

Since Mixin is transparent, the code is open to all users and developers to review and improve, in the same way that Linux is thought to be more secure than Windows, Mixin should rapidly become more secure than any closed source exchanges.

Mixinには透明性があり、コードはすべてのユーザーとデベロッパーのレビューと改善に対してオープンなので、LinuxWindowsよりも安全であると考えられるのと同様に、Mixinはほかのどのクローズドソースの取引所よりもすばやくより安全になるはずだ。

Governance ガバナンス

We try our best to make Mixin Network simply work without any heavy-handed governance, but there are still situations that may require intervention.

私達は、重たい手動管理は何もなく、Mixinネットワークを単純に機能させるように最善を尽くしますが、それでも介入が必要な場合もあります。

XIN is the only stake to determine how the governance work on all the Mixin problems.

XINはすべてのMixinの問題についてどのようにガバナンスが働くか決定する唯一のステークです。

The vectors that can be voted to governance are listed.

ガバナンスのために方向性できる方向性がリストされます。

1.Amount of Kernel Node penalty, mainly assessed when double spend, or fraudulent assets are detected.

1.主に2重支払いや不正な資産が検出されたときに関する、カーネルノードのペナルティの量

2.Asset and Domain registration, determine which assets are to be added to the Mixin Kernel. This may be programmed automatically in the future.

2.どの資産をMixinカーネルに追加するかを決定する、資産とドメインの登録。これは将来自動的にプログラムされる。

3.External asset assurance, e.g. how to recover when Bitcoin forks after the domain finality threshold.

3.外部資産の保証。たとえば、Bitcoinのフォークがドメインのファイナリティしきい値を超えた時にどのように回復するか。

4.Kernel development and upgrade. Determine some policy in the Mixin Kernel specification and upgrade procedure.

4.カーネル開発とアップグレード。Mixinカーネルの仕様とアップグレード手順について、いくつかのポリシーを決定する。

5.Community development, vote on community issues if critical.

5.コミュニティ開発、重大であればコミュニティの問題への投票。

XIN - The Token XINトーク

XIN is the sole token used by many services in Mixin, including full node collateral, DApp creation and API calls.

XINは、フルノードの担保やDAppの作成とAPIコールを含む、Mixinの多くのサービスで利用される唯一のトークンです。

To join the network as a full node, one must pledge at least 10,000 XIN token to establish initial trust.

ルノードとしてネットワークに参加するには、最初の信頼を確立するために、少なくとも10,000XINトークンを担保にしなければなりません。

Every new act of DApp creation will have a one-time cost in XIN, the amount of which is determined by the resources the DApp claims to consume.

新規のDApp作成は、ワンタイムのXINコストを負担する。その量はDAppが消費することを要求するリソースによって決定される。

The Mixin API calls from DApps may cost some XIN well, depending on the call type and count.

DAppからのMixinのAPI呼び出しもまた、呼び出しの種類や回数によっては、いくらかのXINを消費し得る。

All XIN penalties and fees charged by the network will be recycled to the mining pool.

ネットワークによって請求されるすべてのXINペナルティと手数料は、マイニングプールにリサイクルされる。

1,000,000 permanent total XIN token is issued to the world at one time, and 400,000 of them have been successfully distributed to holders from 25/11/2017 to 25/12/2017 with rate 20 EOS/XIN.

発行上限の1,000,000のXINトークンが一度に発行され、そのうち400,000がEOS/XINが20の率でホルダーに配布されました。

50,000 XIN have been distributed to early Mixin Messenger adopters. 50,000 XIN are reserved for the development team.

50,000XINは初期のMixinMessengerの参加者に配布され、50,000XINは開発チームに予約されています。

The remaining 500,000 XIN will be the incentives for all Mixin full nodes and light nodes.

残りの500,000XINはすべてのMixinフルノードとライトノードのインセンティブになります。

Conclusion まとめ

We have proposed the Mixin Network as a multi-layer distributed network.

我々はMixinネットワークをたそう分散ネットワークとして提案しました。

The core layer (Mixin Kernel) is a highly distributed transactional network designed according to the ABFT directed acyclic graph.

コア層(Mixinカーネル)はABFT有向非巡回グラフに従って設計された高度に分散されたトランザクションネットワークです。

The Mixin Domains layer is quite extensible without any overhead to the Mixin Kernel performance.

Mixinドメインレイヤーは、Mixinカーネルのパフォーマンスに対するオーバーヘッドなく、非常に拡張性があります。

We also have a thorough security proof that when managing external blockchain assets, Mixin is secure for daily usage compared to almost any existing cold storage solutions.

私達はまた、外部のブロックチェーンの資産を管理する場合に、殆どの既存のコールドストレージソリューションと比較して、日常の利用にMixinは安全だという、安全性を証明したものだと考えている。

The most important thing is that Mixin isn’t inventing any new things, and all technologies described in this paper have been used as modules in existing mature projects.

最も重要なことは、Mixiはなにか新しいものの発明ではなく、本稿で説明されるすべてのテクノロジーが、既存の成熟したプロジェクトのモジュールとして使用されてきました。

The Mixin Messenger app has proved that this paper is feasible to be implemented in real world, unlike most other projects that have beautiful new theories but no evidence that their work can actually be implemented in the real world.

Mixi Messengerアプリは、美しく新しい理論を持つが彼らの仕事が実際に現実世界で実装されるのか証拠のないような他のほとんどのプロジェクトと違って、本稿が現実世界で実装することが可能だということを証明しました。