Connext v2.0がメインネットに登場
私たちが構築した理由
Rinkebyのテスト、監査、バグフィックスに約2ヶ月を費やした後、私たちは今日、Connextのv2.0をデプロイしました 🌟
- Connext v2.0の開始にはクイックスタートガイドが有用です
- 何か質問があれば、Discordで対応します
- コードはGithubで入手可能です
- 現在進行中のRinkeby v2.0 Dai Cardはこちらで公開されています
- メインネットのv2.0 Dai Cardのリリースはもうすぐです。
V2.0は、Counterfactualを統合すると、最終的にステートチャネルフレームワーク(Ethereum上のチャンネルの統一標準)もサポートすることができます。
どのように動作するのか?
技術の概要はテストネットの投稿をご覧ください!
なぜV2.0が重要なのか?
2年前、私たちはシンプルな質問からConnextをスタートしました。
「どうすれば10億人のユーザーをイーサリアムに呼び込めるのか?」
ということです。
この問いは、スケーラビリティやUX、イーサリアムの転送など多岐に影響するものであり、多くの製品のイテレーションを私たちにもたらしました。私たちは、エンドユーザーが、ガス用のETHを保有しているかどうか、ブロックチェーンがどのくらい混雑しているか、どのサイドチェーン/プラズマチェーン/シャードにいるかどうかにかかわらず、ウォレットやアプリケーションでシームレスかつ一貫した体験を提供する必要がある、という仮説を立てました。
今年の初めにv1 Dai Cardをリリースし、このような反応を見たとき、私たちは何か重要なことを発見したと思いました:
v2.0を構築するにあたって、私たちの目標はシンプルでした。まず、Connextでユーザーが既に気に入っている部分をさらに強化すること。これは、Connextの統合をよりシンプルにすること、リンクによる簡単なオンボーディングをデフォルト実装すること、そして既に魔法のような転送をより速くする努力を続けることを意味します。
2つ目は、Connextを主にウォレット間のネットワークとして再構築し、dAppsがその特定の用途のためにフックすることができるようにしたことです。具体的には、鍵の管理とストレージについて、既存のウォレット開発パラダイムとよりシームレスに動作するようにConnextクライアントを設計し直しました。
3つ目は、ユーザーの最大のペインポイントへのアプローチを見直すことです。v1では、Connextの最も困難な部分は、チャネルオンチェーンへの入金と出金のプロセスでした。v2.0では、入出金をシンプルにしただけでなく、ウォレットがユーザーのチャンネルのプロバイダをdAppに注入することを可能にし、ユーザーが複数のチャンネルに入金する必要性を無くしました。また、v1ではプロトコルが柔軟性に欠け、ユーザーからのフィードバックに対応するのに数週間から数ヶ月かかるという大きな問題がありましたが、v2.0では、新しいアプリケーションや機能のサポートを数日で追加することが可能となっています。
4つ目は、より信頼性を重視した分散型システムへ向けて、有意義な進歩を遂げることです。真の分散化はまだ少し先となりますが、私たちは完全な非親密性へと移行することに成功し、将来的にプロトコルをあまり変更せずにライトニングスタイルのマルチホップを実装するための土台を構築しました。この点については、後述の「信頼性の前提」で説明します。
Connext v2.0は、これまでコミュニティから寄せられた素晴らしいフィードバックの集大成であり、日々の使用に耐えうるEthereumレイヤ2への第一歩でもあります。これまでの私たちの素晴らしい旅にお付き合いいただき、ありがとうございました!
信頼性の前提
Dai Card on v1をリリースした際、私たちのネットワークの主な「信頼性の前提」をリストアップしました。今回は、今回のアップデートで新たに追加された項目を中心に、これまでの前提条件をおさらいしてみましょう。
[修正] 飛行中、一部の決済がカストディになる不具合
v1では、ユーザーファンドは常に非保管でしたが、転送自体はハブによって保持されることがありました。これは特に、リンク支払いやオフラインの受信者への転送など、より条件付きの転送に当てはまるものです。
v2.0では、全ての送金が、完全に非保管化されました。ハブは、あなたの資金を盗むことはできません。これは、v2.0がチャンネルにおける一般化された状態更新をネイティブにサポートし、チャンネルに多くの柔軟性を与えたことで可能になりました。
[修正] ハブは状態の「マスター」コピーを保持し、クライアントはデフォルトで状態をバックアップしない
v1では、オフラインになった場合、ハブが状態を保持する唯一のエンティティでした。これはクロスデバイスの互換性という点では素晴らしいのですが、状態を正確に復元し、紛争時に真実を伝えるためにハブに依存してしまうことを意味します。私たちは当初、IPFSに状態をバックアップすることでこれを解決するつもりでしたが、方向転換しました。
v2.0では、状態の保存とバックアップはウォレットに任されています。ユーザはチャネルを実行するために状態のローカルコピーを持っている必要があり、状態の永続的な「作業コピー」として機能しますが、ウォレットはリモートバックアップを作成する必要があります。クライアントは、デフォルトではハブから状態を回復しませんが、エンドユーザーがオプションとして選択することで有効になります。また、チャンネルの紛争をチャンネル所有者のみで解決することを要求しなくなったことにより、ウォレットプロバイダがユーザーのための監視役として機能することが可能になります。
[進行中] アップデートがhttp経由で行われ、検閲可能に
v1では、ハブはRESTサーバで、クライアントはhttpのPOSTでアップデートを通信していました。これはシンプルな良い戦術でしたが、ハブが状態を更新するためにリクエストベースのフローを義務付けられ、更新を検閲できることを意味しました。
v2.0では、スケーラブルで軽量なオープンソースのP2PメッセージングシステムであるNATSに移行しました。NATSは、http-requestのパラダイムからハブを移動させ、状態の複数の独立したコピーを持つことができるようにします。これを正しく動作させるためには、メッセージングサーバー(現在はハブがホスト)を実装する必要があり、p2pになったとはいえ、集中管理されたv2.0ハブ内のメッセージは、v1のように検閲可能なままなのです。
この点に対してNATSを使用するという決定は、この問題を解決するための一歩となります。NATSは、多くのメッセージングサーバーをクラスタリングすることで、分散型(メッシュ)メッセージングをサポートします。つまり、クラスタ化されたNATSインスタンスをConnextノードの一部としてリリースすることで、メッセージングレイヤーを同時に分散化することができるのです。
[進行中]転送はハブを経由して行われ、検閲可能に
v1では、全てのユーザがハブにチャンネルを預け、ハブを介して互いに転送をルーティングしました(0x中継器の仕組みに類似)。これは、ユーザーデータを収集し、さまざまなユースケースをテストする間に、信頼性が高く、容易に反復可能なシステムを構築するためのブートストラップ手法でした。これは同時に、ハブが検閲、DDoS、シャットダウンされ、Connextの決済サービスがオフラインになる可能性があることも意味します(ユーザーの資金は失われません)
v2.0のローンチ時には、同じパラダイムを使用しており、検閲を受ける可能性があります。真の意味で分散型ネットワークになるには、まだやるべきことが多く存在します。しかし、P2Pメッセージングと一般化された状態を追加したことは大きな一歩といえるでしょう。Connextは、システムを書き換えたり、インターフェースを大幅に更新したりすることなく、より拡張性の高い転送プロトコルを迅速に反復できるようになりました。
[New] ハブのインターフェイスを介したクライアントのプロキシによるRedlockへのアクセス
ユーザーの状態を保存するストレージを分散化することで、状態の同時更新に関連する複雑さを導入しました。集中型サーバーでは、操作のたびに状態をロック/アンロックすることで並行処理を行います。Connextの分散パラダイムでは、Redisの分散ロックをハブに統合しました。残念ながら、Redisはブラウザでネイティブにサポートされておらず、ブラウザベースのRedisインターフェースであるWebdisもRedlockをサポートしていません。
そこで、効率的な出荷のために、クライアントが状態をロック/アンロックするために、ハブがホストするプロキシインタフェースを構築しました。短中期的には、Webdisも分散ロックを使用するように再実装または修正することが期待されます。
技術的な詳細
コントラクトは独立した監査を受けています:
メインネット・コントラクト:
- ChallengeRegistry.sol
- ConditionalTransactionDelegateTarget.sol
- CoinBalanceRefundApp.sol
- MultiAssetMultiPartyCoinTransferInterpreter.sol
- IdentityApp.sol
- MinimumViableMultisig.sol (singleton)
- ProxyFactory.sol
- SingleAssetTwoPartyCoinTransferInterpreter.sol
- TimeLockedPassThrough.sol
- TwoPartyFixedOutcomeInterpreter.sol
- TwoPartyFixedOutcomeFromVirtualAppInterpreter.sol
- SimpleTwoPartySwapApp.sol
- SimpleLinkedTransferApp.sol
- SimpleTransferApp.sol
コントラクトコード:
そして最後に、もしあなたがConnextの取り組みを面白いと感じたら、周りの暗号/ブロックチェーン好きな友人と共有してください。私たちは、ウォレット、ブラウザ、アプリケーションにおいて、イーサリアム上での即座に低コストな取引を実現させていきます。
これまでも、これからもご支援ありがとうございます。
Team Connext