SwiftDemandホワイトペーパー(原案)和訳β版2

警告

1.筆者と私の解釈がずれている可能性があります。

2.翻訳をした際に意味が変わってしまっている可能性があります。

 

どうか公式のホワイトペーパーをご覧ください。

GitHub - swiftdemand/swiftprotocol: The white paper for the Swift Protocol

------------------------------------------------------------------------------

要約

Swiftプロトコルは、ユニバーサル・ベーシック・インカムを提供する分散型自治組織(DAO)を実装したプラットフォームです。

 

Swiftは、様々な形の取引を想定し設計された通貨です。

素早い決済速度、１秒間に数千もの取引処理を可能とする容量や取引に関する様々な問題解決を可能とするために作られました。

日々基本的収入を全ての参加者に分配することで、ユニバーサル・ベーシック・インカムを実現します。

 

このホワイトペーパーはSwiftプロトコルの仕組みを明確にするために書かれました。

 

概要

ユニバーサル・ベーシック・インカムとは、今後仕事が自動化し続ける中で人類が機能し続けるために必須となる現社会システムへの反抗です。

私達は、人類の歴史上で最もリソースが豊富な社会を生きています。

しかし、それでも生活を続けるために苦労をする人々が存在しています。

全ての人々が生活必需品を手に取れるような社会を作るのが私達の人類の一員としての義務です。

Swiftプロトコルでは、ユニバーサル・ベーシック・インカムの分配を目的としたDAOの仕組みを作ろうという提案をします。

Swiftプロトコルが世界的に導入されることで、ユニバーサル・ベーシック・インカムを実現します。夢では終わらせません。

このプロトコルは実用的で実績のある解決策と大量採用を支援する追加機能を持って設計されました

 

アカウントの種類

ベーシックインカムを提供し、取引に実用的な通貨を作るために以下の形態構造が必須となります：

 

1.BIを受け取る口座の所有数は一人につき一つであるべきです。

 

2.ビジネス及びプライバシー上の理由により個人情報と結びついていないアカウントの存在は許されるべきです。

 

3.単一障害点を避けるためにシステムは分散化されたまま維持されなければなりません。

 

4.変化する活発な経済のニーズに対応するために、規則は時間と共に変更可能な状態にあるべきです。

 

 

Swiftプロトコルを成功させるため、4つの異なるアカウントタイプがそれぞれ違う役割を担います。

 

・スウィフト市民（Swift Citizens)

スウィフト市民とはゲートによって承認を受けたアカウントです。

市民は一日一回ブロックチェーン上に請求を追加する権利を持ちます（一日の始まりは世界標準時の0時を基準とします）。

Swiftは、上限を７日間として経過日数に基づいて与えられます。

例えば、現在の1日分の分配量である100Swiftを3日間の非請求状態を終えた後に請求を行った場合、300Swiftが付与されます。

 

・スウィフトアバター（Swift Entities）

スウィフトアバターは現実世界の個人情報とは結びついておらず、ベーシックインカムが与えられないアカウントです。

ただし、作成される前にゲートによる検証を受けなければいけません。

全てのスウィフトアバターはゲートとリンクされなければいけません。

しかしながら、ゲートをアカウントの代わりに使って取引することは許可されて下りません。

コーディネーターとゲートは両者ともスウィフトのアカウントタイプを継承します。

 

・コーディネーター（代理ノード/Delegated Nodes）

各コーディネーターはフルノードを維持し、新たにブロックを作成する責任を持ちます。

各選挙期間内にスウィフト市民は自身の代表者として選択したコーディネーターに投票をします。

これはコーディネーターが他のコーディネーターやゲートの提案を採決する権利を持ち、市民に選ばれた代表者として行動することを意味します。

 

・ゲート（入国審査官及び取引監査員/IDプロバイダー/Identity Providers）

ゲートには、各スウィフト市民の身元を確認し新たに市民を迎え入れる際にブロックチェーン上に個人情報を含めペアキーを生成する義務があります。

 ゲートには購入者と販売者を保護するため、各々が所持するスウィフト市民のキーを守護する義務があります。

 

ゲートは以下の権利を持ちます：

 

・新たに市民を迎え入れる権利

 

・各々が承認した市民を凍結、及び解凍する権利

 

・各々が承認した市民の代理取引をする権利

 

・各々が承認した市民を抹消する権利

 

・孤立した市民を救出する権利

 

所得の分配

Swiftプロトコルは、全てのスウィフト市民に対するSwiftの公平な分配方法の提供を目標としています。

さらに、分配方法にはSwiftの発行量によって値の減少を起こさない仕組みを使用しなければいけません。

現在の成熟した経済が形成された状態（世界市場）に素早く到達するために、ステージ１中に早期ユーザーは追加のSwiftを受け取ります。

Swiftは、非請求日数の上限を７日間として日々ユーザーに配布されます。

スウィフト市民は、非請求分のswiftを得るために、少なくとも週に一度確実にSwiftを請求しなければなりません。

日数は00:00UTCから23:59UTCの間に発生するブロックによってマークされています。

ステージ１で経済に組み込まれるSwiftの総量は700億枚と想定しています。

このステージに到達した後、ステージ2では経済に健全なインフレ率をもたらす為に、システムに組み込まれるSwiftの量を制限します。

 

ステージ1

ステージ１では、経済を短期間で成熟させる為にSwiftの生成率を加速させます。

このステージ中には、スウィフト市民はシステム上に存在するスウィフト市民の数によってSwiftを受け取ります。

所得分配の乗数の計算式は：

(781250 / (5^(log10(users))))となり、最大値を100、最小値を1とします。

 

ステージ2

ステージ１の計算式に基づいて発行数が700億の上限に達した後、ステージ２が始動します。

このステージ中では、新しいSwiftはコーディネーターによって決められたインフレ率に基づいて、システム内の全てのユーザーに分配されます。

十分に分配が行われているのを確認し、発行済みのSwiftの値の減少を避けながらインフレ率を選択するのが彼らの義務です。

 

分配に関する各地域の乗数

各地域で掛かる生活費に基づいて収入クラスが変化します。

これらのクラスや乗数はコーディネーターによって決定されます。

各市民が所属する地域は、市民がブロックチェーン上に登録される際にゲートによって検証されます。

これらの乗数の範囲は0.01xから1.0xです。

 

TIP:CEOに確認したところステージ１で実装予定

ただし、現在のユーザーは数カ月間適用外にするかもと言っていました。

プラン：後に来る人々が受け取るBIは少なくなっていくので、それに合わせて現存のユーザーの保有するSwiftの価値を各地域の乗数にマッチするまでゆっくりと下げていく。

・これに関してはまだ100%確証ではないとのこと

紹介報酬システム

市民が新しく迎え入れられる際、紹介者のパブリックキーを含めるオプションが存在します。

紹介者ボーナスは５×(781250 / (5^(log10(users))))の計算式により算出されます。

例えば、紹介時に100,000人のスウィフト市民がいた場合、紹介ボーナスは500swiftとなります。

 

分散型自治組織(DAO)をベースとした統治システム

統治システムは、外部データを使用したユーザーの身元確認や経済管理が安全に行われる為にSwiftプロトコルには必要不可欠な要素です。

しかしながら、Swiftプロトコルの自律的分散型の仕組みによって鉄則を定めます。

これらの鉄則は、中央集権型のシステムで可能となっている不正行為を防ぐことを保障します。

 

Swiftプロトコルは分散型の政府をシミュレートする内部システムを備えています。

スウィフト市民は政府内で様々な権利を得るコーディネーターを選択する義務を持ちます。

このコーディネーター達にはブロックチェーンを維持し、新たなブロックを鍛造し提案を採決することが求められます。

 

コーディネーターの選挙

各スウィト市民は各選挙中にネットワーク上で一票を投じる権利を持ちます。

選挙での投票数が最も多かったコーディネーターはその任期中に勤める者として選ばれます。

コーディネーターの人数は次の計算式によって決定されます：

 

(users/100,000) 又は10、数字が大きい方

 

Tip:初期の初期段階には実際はSwiftDemandチームから3-5人ほどだけがコーディネーターを担当しますが、Swift経済が安定してくるとSwiftDemandに限定されたものではなくなり誰もがコーディネーターになれます。

 

選挙期間

選挙は最初の5年間、6ヶ月ごとに行われます。

市民は各々が好んだコーディネーターに投票するために２週間の猶予を持ちます。

投票期間が終了した後、当選したコーディネーター達が意識を高め、チェーンの内部分裂を防ぐ為の1ヶ月間の猶予期間が始まります。

 

コーディネーターの投票 

コーディネーターは以下の権利を持ちます：

 

・新たにゲートを選ぶ権利

 

・既に存在しているゲートを退任させる権利

 

・過去72時間以内の状態にブロックチェーンを戻す権利（リバース）

 

・コーディネーターを退任させる権利

 

・コーディネーターの代わりを選択する権利

 

・地域ごとの収入クラスの基準を選ぶ権利

 

・ステージ2でのインフレ率を選択する権利

 

・コーディネーターの給料に関して投票する権利

 

・ゲートの給料乗数に関して投票する権利

 

・資金調達を要する企画に投票する権利

 

これらの権利を機能させるために、企画書は少なくとも一人のコーディネーターによってブロックチェーン上に提出される必要があります。

 その後、ネットワーク上のコーディネーター全員が企画書に投票します。

提出から２４時間以内に全体の５０％+１票の受け取った企画は可否されます。

 

トランザクション機能

Swiftプロトコルは取引に実用的な通貨として設計されています。

これは、Swiftを介した換金は従来の銀行システム程度に安全な必要であることを意味します。

ボタン一つ押したりクレジットカードをスワイプするだけで実行されるような簡単な送金システムを可能にする為、４つの主要な機能が実装がされています。

 

トランザクション処理速度

コーディネーターがネットワークを制御する性質のため、ノードは１ブロック当たり３秒と非常に早い速度で鍛造することができます。

POSを実装した他のアルゴリズムでは、このようなシステムを１秒当たり50,000トランザクションまで拡張できることが可能であると証明されています。対照に、ビザは１秒当たり24,000トランザクションまで拡張可能です。

 

安価なトランザクション手数料

SwiftDemandには固定のトランザクション手数料はありません。ゲートはトランザクション手数料を設定する権利を持ちます。

 

そのため、彼らにはトランザクション紛争を解決する為の資金保有を許可します。

Swiftプロトコルは80％の各ブロックをゲートのみが使えるようにスペースの予約をします。

スペースはゲートによってさらに分割されます。

これにより、スウィフト市民の数に比例してブロックごとに最低10件のトランザクションを確認します。

 

したがって、ゲートにはチェーン上にスパムトランザクションが追加されないよう保証する義務があります。

各ブロックの残り20％は入札システムのために設けられます。これは、ビットコインが機能するための仕組みに似ています。

 

買い手/売り手の保護

トランザクションはスウィフト市民のプライベートキーかゲートのプライベートキーによって署名することができます。

これにより、ゲートはトランザクションをリバースさせることができます。

許可されていないトランザクションは、プラットフォーム上での買い手ー売り手間の紛争を解決する為にのみ使用されるべきです。

資金のリバースが不可能な場合、ゲートはトランザクション手数料によって得た自己資金を問題解決に使用する義務を持ちます。

 

トランザクション承認時間

単一のトランザクションの承認は通常発行後３秒以内に実行されます。

市民が行う日常的なトランザクションは、スウィフト市民の代わりにゲートにより署名されるのが好ましいです。

従って、ゲートによって署名されたトランザクションは高い信頼性を持ちます。

ゲートがスパム攻撃を試みることはまずありえないので、一つの承認で信頼できます。

個々の市民によって署名されたトランザクションは他の複数のトランザクションが優先的に承認されるまで待つ必要があります。

これは、Bitcoinのホワイトペーパーに記載されているのと同様のロジックに従っています。

 

手当て

コーディネーター及びゲートへの手当てはSwiftプロトコルの仕様の一つです。

この手当ては重大な財政的損失を招く恐れがある不正行為を阻害するために使用されます。

また、この手当ての利点は資金を枯渇させず、経済全体が永久に円滑に機能し続けることを保証することです。

 

コーディネーターとゲートの両者は提供したサービスに対しての給料がSwiftで支払われます。

給料は、毎日スウィフト市民達がベーシックインカムを得るのと同時に支払われます。

 

生成されたSwiftは初期段階で通常分配されるSwiftのプールより70%が引き出されます。

プールの分配が完了すると、ステージ2で加えられるインフレ率分の給料用のSwiftが生成されます。

 

コーディネーターの給料

全てのコーディネーターは同等の給料を受け取ります。各コーディネーターは自分達の給料に投票します。

ただし、給料は前回の給料より一定の割合内にとどまる必要があるという制約があります。

コーディネーターがこの権限の乱用を試みた場合、彼らの退任投票を行うのがスウィフト市民の役目です。

 

ゲートの給料乗数

ゲートの給料はコーディネーター達によって決定されます。

ゲートの給料は特定のゲートの下で市民が請求したSwiftの数を給与乗数で乗算することによって決定されます。

例えば、給与乗数が0.01で、ゲートの下で総額500万のSwiftを請求した10万人のアクティブな市民がいた日には、ゲートは00:00時(UTC)に初期のブロックから5万Swiftを受け取ります。

 

予約資金

300億Swiftは予約されます；これらのSwiftは中央集権型の制御を受けていません。

 

コーディネーターはこれらの資金を過半数の投票により、様々な提案に授与する権利を持ちます。

 

Swiftプロトコルの成功に努め、各コーディネーター、スウィフト市民、スウィフト法人とゲートに必要な分に応じてこれらの資金を割り当てるのはコーディネーター達の役目です。

 

資金調達の提案

スウィフト市民又はゲートが何らかの企画を行う為に資金を要する場合は、資金調達のため企画書を提出しなければなりません。

 

この企画書はプレーンテキストで書かれ、企画者のプライベートキーによって署名された後、ブロックチェーン上に追加されます。

コーディネーター達の企画案への投票期間は1週間です。無票の企画案は否決と見なされます。資金が移転されるためには大多数の合意が必要となります。

 

合意プロトコル

Swiftプロトコルでは、信頼性を維持しながら迅速なブロック生成を可能にする新しい合意メカニズムが使用されています。

Swiftプロトコルは、DPOI（delegated Proof of Identity）と呼ばれる新しい合意メカニズムを使用します。

これは、ほとんど(delegated Proof of Stake)と同じメカニズムです。

両者の主な違いは：

DPOSでは人々の通貨の保有量とステーク量が比例するに対して、

DPOIでは各スウィフト市民はステーク量に関係なく一票を投じることができるということです。

 

鍛造者達の選択

コーディネーター達が選出されたとき、彼らはブロックを鍛造することが許可された順にリストアップされます。

順位は、各コーディネーターが選挙中に得た投票数によって決まります。

コーディネーターはラウンドロビン方式でブロックを順番に鍛えていきます。

ブロックを鍛造する順番が回って来たコーディネーターには、１０秒間ブロック生成用のウィンドウが表示されます。

時間内にブロックが生成されなかった場合、リストに載っている次のコーディネーターにもブロックを鍛造する権限が与えられます。

これは、タイプスタンプサーバーを使うことで達成できます。

 

合意

合意は最長のチェーンを基に判断されます。

複数のブロックに署名をすることで、ダブルスペンド攻撃を試みたコーディネーターは速やかに他のコーディネーター達によって凍結されます。

 

保護

Swiftプロトコルによって実施される分散型政府制度には慎重に分析すべき潜在的な攻撃可能経路が存在します。

 

これらの攻撃を潜在的影響力とともにその対策法を解説します。

スキップ攻撃(Skip Attack)

もし、コーディネーターが＜悪＞＜正義＞＜悪＞の性質をもった順で並んでいた場合には、2人の悪のコーディネーターが結託して正義のコーディネーターをスキップできます。

最初にブロックを生成するのが悪のコーディネーターの場合、ブロックは直ちに生成され、リスト内の次の悪のコーディネーターにのみ送信されます。

次に、2人目の悪のコーディネーターは10秒間待機し、ノードに署名し、そして、通常通りに送信されます。

すると、2人の悪のコーディネーターを含めたチェーンは他と比べ長いため優先されます。

通常この攻撃は無害ですが、悪のコーディネーターが最適に配置された場合、悪のコーディネーター達で結託し25%+1の状態でネットワークを操作することができます。

 

インキュベーション期間

Swiftプロトコルに新たに加入する全てのスウィフト市民は1週間ほどインキュベーション期間に置かれます。

これにより、ゲートによるSwiftを手に入れる目的でのスウィフト市民偽造行為を阻止します。

さらに、他のコーディネーター達に不正行為を試みたゲートを凍結するための十分な時間を与えます。

 

シビル攻撃(Sybil Attack)

ゲートはシビル攻撃を実行することで麻痺し、コーディネーター達によって凍結されるリスクを伴います。

インキュベーション期間やブロックチェーンの巻き戻し機能などの追加の保護手段は、様々な不正行為を阻止するのに役立ちます。

スウィフト市民は自身のBIの割合を増やす目的で偽の書類を提出することができます。

しかし、不正行為が確認された場合には両方の収入源を失うことになります。

いくつかの偽のアカウントが作成されることが予想されるため、ゲート達はスウィフト市民をどのように承認するかについて厳しい規制を課す必要があります。

 

ラウンド・ロビン・オーダー(Round Robin Order attack)

悪の組織は、全員で結託することで同様の投票数を受け取ろうと試みる可能性があります。

これによって、ラウンドロビンの順序内の同様の場所に彼ら自身を配置することができます。

ダブルスペンド攻撃は、その後少数の悪のコーディネーター達によって完成させることができます。

ただし、この攻撃は検出される前の一度しか発生することはないでしょう。。

大規模なトランザクションは、これに対抗するため十分な承認を待つ必要があります。

小規模な取引は、ゲート達によって保証されるべきです。

 

ゲートの凍結

ゲートが不正行為を試みた場合、コーディネーターによって凍結されます。

ゲートの不正行為が既に行われ被害が発生している場合、コーディネーター達はチェーンを元の状態に戻すかを投票することが出来ます。

これは、膨大な経済的被害をもたらしますがSwiftプロトコルが攻撃によって荒らされないようにし、ゲート達の不正行為を野放しにしないようにするための最後の手段として用意されています。

各ゲートに属するSwiftアカウントは、他のゲートによって承認されるまで孤立します。

 

規則

事実、Swiftプロトコルは非中央集権型の政府を通じて実世界とリンクするためプログラムにより強制できない一定の規則が存在しますが、Swiftプロトコルが意図した通りに機能するためには不可欠な規則なのです。

規則に記載されている項目に反する行動を行ったコーディネーター又はゲートは凍結されるべきです。

 

・地域別水準は、スウィフト市民が合法的移住者である地理的領域に関連した生活費に基づいていなければなりません。

 

・ゲートはシビルアカウントを作成できないようにするため、分散型IDの内部システムを共有する必要があります。また、内部システムはスウィフト市民の潜在的な移行を容易にするべきです。

 

・コーディネーター達は以下の理由により凍結されます：

 

- 定期的に企画案に投票する義務を行わなかった場合。

- dBFT以内に新たにブロックを鍛造しなかった場合。

- 自分を支援していないブロックデータの受け入れを拒否した場合。

- 有害な偏見によるで非合理的な政策への投票。

 

・正式アナウンスは、偽造を防ぐ為に毎回署名されるべきです。

 

・インフレ率は以下の注意点を考慮した上で調整されるべきです：

 

- 現存のSwiftの不要な暴落を招くインフレ率

- インフレ率の変化から生じる実世界への影響

- 基本的な生活必需品を揃えるために必要な収入の量

 

・ゲート達は以下の理由により凍結されます：

 

- 意図的か否かに関わらず、シビルアカウントを受け入れる脆弱な承認プロセスを行った

- トランザクションに適切な紛争解決を提供できなかった

- 新たにスウィフト市民を承認する義務を果たさなかった

- プラットフォーム上で他のゲート達に非協力的だった

 

・資金調達のために承認された企画は、プロトコルの初期段階では相対的に自由なままになりますが、時間経過と共に徐々に厳しくなるはずです。

 

・ゲートは１週間のインキュベーション期間が設けられトランザクションの処理には数秒間かかることがあるという知識からユーザーを保護する必要があります。

ユーザー側の観点から、SwiftDemandは中央集権型のシステムに決して劣らず、効率的に機能するように見えることが重要です。

もし、システム稼働中に問題が発生した場合、状況を改善する為に損失を被ってでも自己資金を使うのがゲートの義務です。

 

SwiftDemandへの継続

 

Swiftプロトコル上で解説した通りになります。

SwiftDemandはSwiftプロトコルで最初のゲートになります。

SwiftDemand内に存在する全てのSwiftは、スウィフトメインネットの起動時に１：１の比率で転換されます。

スウィフト市民は、現時点ではKYCとAMに準拠するために厳格な身元確認の要件を遵守する必要があります。

 

SwiftDemandの機能

SwiftDemandは仮想通貨の事前知識を必要とせず、ユーザーに非常にフレンドリー（将来のゲート達のための基準設定をすること事も含め）なプラットフォームになるように設計されています。

SwiftDemandは商品やサービスのためにSwiftをできるだけ簡単に転送できるAPIとマーケットを提供します。

 

＜注意＞

このSwiftプロトコルは時間経過と共に進化できるように設計されています。

新たな技術が開発されたり、システムの改善点が明らかになることで進化していくでしょう。

当初の目的であるユニバーサルベーシックインカムの配分は決して変わりません。

 

将来起こりうる変更や改善の例を下に示します:

 

- シビル攻撃の対抗手段として有効であることが証明された場合、サークルに類似した分散型手法によって身元確認が行われるかもしれません。

- 身元確認とプラットフォームを営む義務の分離。

-偽造アカウントを探し出すための賞金プログラム

- ゲートが提供するスマートコントラクトの強制保険システム

- 独自の通貨を持つ各国のサブシステムを持ちながらも自動的に通貨同士を交換可能にするシステム

- 対シビル攻撃の保護を強化するためのハッシュされたバイオメトリックデータ。