SQL によるスマート コントラクトの拡張

フィードバックと洞察を提供してくれた DePHY Network の Jun Jiang 氏と Usher Labs の Ryan Soury 氏に特に感謝します。

2008 年、ウォール街の警報が鳴り響き、洗練されたトレーダーたちは原始的な狂乱に陥った。過剰レバレッジの金融機関はサブプライム住宅ローン担保証券の重圧で崩壊し、貪欲な銀行家たちは危険にさらされ、救済を懇願することになった。中央銀行は権力を維持しようと必死になり、一般市民の小切手から銀行家の罪を償った。この裏切りにより、中央集権的な通貨システムの欠陥が明らかになり、より新しく、より自由で、より公正な金融システムの必要性が明らかになった。アメリカ独立戦争とそれに続く憲法が政教分離をもたらしたように、ビットコインと呼ばれる新たな革命が生まれ、通貨と国家を分離し、自己決定の基本となる多くの自由と権利を可能にした。

ブロックチェーン技術は自由の技術です。これにより、中央集権的な仲介者への信頼を必要としない金融、アイデンティティ、情報、社会調整システムを構築できます。中央銀行がお金の流れをコントロールせず、単一のプラットフォームが社会的言説をコントロールせず、単一の企業がデジタルアイデンティティをコントロールしない世界では、個人の自由が繁栄します。

この新しい世界と現在の世界との違いの多くは、ブロックチェーン プラットフォームの技術的機能にあります。第一世代のスマート コントラクトは、これらの自由システムを可能にした氷山の一角でしたが、その機能は根本的に限られています。この記事では、現在のスマート コントラクトの重大な制限のいくつかと、新しいシステムである「SQL スマート コントラクト」が、人間の自由を解き放ち、新しいコンピューティング プラットフォームとしてのブロックチェーンの可能性を実現するための、より技術的に優れた基盤をどのように提供するかについて説明します。

スマート コントラクト: 真実の機械のプログラミング

「根本的な問題は、それが機能するために必要な信頼です。」 - サトシ・ナカモト

ブロックチェーンの本来のコア特性は不変性です。ネットワーク内のステークホルダー (または「ノード」) の一定しきい値が何かが真実であると同意すると、ブロックチェーンはその真実の記録を永続的に保持します。ブロックチェーンは、悪意のある行為者が真実を操作できないようにするために、ノードがコンピューティング能力、金銭的利害関係、または評判の形で大量の価値を費やすさまざまな「証明」メカニズムを使用します。

ビットコインがデジタル通貨の「真実の機械」であるならば、イーサリアムはより複雑な金融商品の「真実の機械」です。イーサリアムは、開発者が一連のノードに展開、検証、実行されるロジックを実装できるプログラム可能な設計スペースを作成することで、ビットコインの機能を拡張します。つまり、通貨だけでなく中央機関への信頼を必要としないシステムを作成できるようになりました。融資、不動産証書、ID情報、ソーシャルメディア、経済指標など、中央機関を必要とするシステムは、中央仲介者なしで運用できるようになりました。これはまったく新しい世界です。

スマート コントラクトとは、開発者がブロックチェーン上に作成してデプロイするプログラムです。ブロックチェーンは、開発者が分散型アプリケーションを作成するためのキャンバスです。「スマート コントラクト」という用語は、2 つの当事者が特定の権利と義務に拘束される法的契約を意味するものではありません。代わりに、「スマート コントラクト」は、アプリケーションがコードに記述されたとおりに無期限に機能することが保証されていることを意味します。貸付契約は、借り手と貸し手が常に取引できることを保証します。不動産契約は、人々が常に資産の所有権を確認し、譲渡できることを保証します。スマート コントラクトは、コードが法律になるアプリケーションです。

スティーブ・ジョブズはコンピューターを「心のための自転車」と呼びました。スマートコントラクトは車輪が決して外れないことを保証します。

イーサリアム スマート コントラクト: 氷山の一角

「暗号通貨は単なるトークンの取引ではありません。自由とプライバシーを保護し、権力を一般の人々の手に留めておくという、より広範な精神の一部なのです。」 - ヴィタリック・ブテリン

Ethereum スマート コントラクトは分散型製品のまったく新しい世界を導入しましたが、その設計とデータ操作機能における根本的な制限により、暗号通貨以外の多くのアプリケーションでは効果を発揮できません。

Solidity (Ethereum のプログラミング言語) では、契約データはキーと値のペアで保存されます。構造体(変数のグループ化) とマッピング(キーと値のペアのコレクション) はデータを整理するのに便利ですが、すべてのデータはキーによってのみ取得できます。ユーザー ID データを保存する理論上の契約を考えてみましょう。

 contract IdentityStorage { // Struct to store KYC details struct identity { string fullName; string dateOfBirth; string residentialAddress; } // mapping a country to its citizens to their info // "Canada" => 0x123… => {Vitalik Buterin, 01/31/1994, ...} mapping(string => mapping(address => identity)) public idData; //...rest of contract }

この契約では、ユーザーの ID レコードは、ユーザーの国とウォレット アドレスがわかっている場合にのみ取得できます。契約のデプロイ者がスマート コントラクトを再設計して、ガス コストの高いデータ操作を行わない限り、契約ユーザーが ID レコードを取得する他の方法はありません。データをキーと値のペアで保存すると、最終的にデータへのアクセス方法と操作方法が制限されます。

特に、Ethereum スマート コントラクトのデータ管理には、インデックス依存性とアクセス パス依存性という 2 つの基本的な問題があります。

インデックスの依存性

インデックス依存性とは、特定のデータにアクセスするには、そのデータがインデックスで利用可能でなければならないことを意味します。インデックスは、コレクション内の一意の識別子を効率的に検索するデータ構造です。上記の KYC 契約の例では、レコードにはキーに使用されている正確な Ethereum アドレスを通じてのみアクセスできます。この厳格なインデックス構造により、契約ユーザーは、「どのユーザーがこの住所を持っているか」や「この国民 ID を持つユーザーのうち、1970 年 1 月 1 日以降に生まれたユーザーの割合はどれくらいか」など、他の基準に基づいてデータを照会することができません。このようなクエリを実行できないと、開発者は契約データを中心に集約、分析、およびアプリケーション ロジックを構築する柔軟性がなくなります。開発者がフルネームで ID レコードを取得するなど、この追加の柔軟性を必要とする場合は、契約全体を再構築する必要があります。Ethereum では、インデックスを再構築すると契約のガス コストも増加し、契約の使いやすさがさらに損なわれる可能性があります。

アクセスパス依存性

アクセス パス依存性とは、特定の取得パスを通じてのみデータにアクセスして理解できることを意味します。サンプルの契約では、Vitalik の国とウォレット アドレスがわかれば、開発者は彼の ID レコードを取得できます。ただし、ウォレット アドレスだけを知っていても、開発者は Vitalik の出身国を取得できません。さらに、開発者が Vitalik のウォレット アドレスを知っていても、出身国 (「カナダ」キー) を知らない限り、彼の ID レコードを取得することはできません。Vitalik の ID レコードへのアクセス パスは固定されているため、開発者がウォレット アドレスのみでレコードを取得する必要がある場合は、契約全体を再構築する必要があります。アクセス パス依存性とは、データが一方向でのみアクセス可能で意味があり、さまざまな観点からデータを照会または解釈する機能が制限されることを意味します。

インデックスとアクセス パスの依存性は、複雑または進化するデータ モデルを必要とするアプリケーションにとって大きな課題となります。暗号通貨には Ethereum で実装できるシンプルなデータ構造がありますが (ERC20 トークンは基本的にアドレスと残高のマッピングにすぎません)、これらの課題はデータ集約型のアプリケーションでは問題になります。アプリケーションが複雑なデータ モデルを保存、クエリ、および操作する必要がある場合、Ethereum の基本的なキー値ストレージではデータ管理が大幅に制限されるため、複雑なデータ管理を必要とするアプリケーションの構築と保守が困難になります。

簡単な歴史レッスン: リレーショナル モデル

「歴史は繰り返さないが、韻を踏むことはよくある」 – マーク・トウェイン

1970 年、IBM のコンピュータ サイエンティストである Edgar F. Codd が、「大規模共有データ バンクのリレーショナル データ モデル」という論文を発表しました。当時、アプリケーション データベースの最も一般的なタイプは「階層型データベース」でした。これは、コンピュータ上でファイルが整理されるのと同様に、各データが親ディレクトリの下に保存される、堅固なツリー構造を採用していました。Codd は階層型データベースに反対し、表形式の構造を持つ、より新しく、よりシンプルで、はるかに高性能なリレーショナル データベースを提案しました。

階層型データベースのツリー構造は、各データの親子関係を理解する厳格なシステムを通じてのみデータにアクセスできることを意味します。特に、Codd は階層型システムに関する 3 つの主要な問題を特定しました。

1. 順序の依存性:クエリの結果は、多くの場合、ストレージ内でのデータの編成方法によって異なります。データが保存されている順序と同じ順序でクエリされることを前提としてアプリケーションが構築されている場合、その順序は将来変更できません。

2. インデックス依存性:特定のデータにアクセスするには、アプリケーションは親 (つまりインデックス) を認識している必要があります。そうでない場合、要求されたデータを取得することはできません。

3. アクセス パスの依存性:データにアクセスしたり理解したりするには、特定の取得パスに従う必要があります。アプリケーションが特定のアクセス パターンを使用してデータを取得するように設計されている場合、代替パスを使用して同じデータを取得したり解釈したりすることはできません。

   
   

聞き覚えがありますか? Ethereum スマート コントラクトには順序依存性がありません (マップは順序付けられていません) が、1960 年代と 1970 年代にデータベースを妨げたのと同じインデックスとアクセス パスの依存性の制限が、今日のスマート コントラクト プラットフォームを妨げています。

データベース レベルの制限は、単なるささいな障害ではありません。開発者を根本的に制約し、プラットフォーム上に構築されるアプリケーションの種類を制限します。インデックスとアクセス パスの依存性と戦う開発者は、新機能の実装に重点を置くのではなく、既存のアプリケーションの機能を維持するために多大な労力を費やす必要があります。1960 年代から 1970 年代にかけて、データベースの使用は主に在庫管理、会計、一般的なデータ処理などの厳格なビジネス タスクに限定されていました。開発者には、より洗練されたアプリケーションを作成するためのデータの柔軟性がありませんでした。しかし、リレーショナル データベースの導入後、はるかに表現力に富み、データ集約型のアプリケーションが登場し、ERP システム、CRM、ビジネス インテリジェンス ツールが台頭しました。さらに、インターネットの出現により、これらの進歩は e コマース プラットフォームやソーシャル メディア アプリケーションへの道を開きました。開発者は、以前はデータベース全体を再構築する必要があった機能を、わずか数行の SQL で実装できました。リレーショナル データベースは単なるパラダイム シフトではなく、根本的に新しいアプリケーションを生み出すカテゴリ作成プラットフォームでした。

現在、ブロックチェーン プラットフォームは 1970 年代のコンピューターやデータベースに似ています。ブロックチェーン レベルでのデータ処理能力が不足しているため、開発者はより高度でデータ集約型の分散型アプリケーションを実装できません。ブロックチェーンの主な使用例が暗号通貨を超えて拡大するとしたら、より優れたデータ処理機能を備えたブロックチェーン プラットフォームが必要です。

SQL スマート コントラクト: より柔軟なパラダイム

「知性の尺度は変化する能力である。」 - アルバート・アインシュタイン

1980 年代のリレーショナル データベースの商用化が新しいアプリケーションの急増につながったのと同様に、リレーショナル データベースをブロックチェーン プラットフォームに統合することで、作成できる分散型アプリケーションの種類が一変する可能性があります。

Kwil では、開発者が SQL の完全な表現力を活用する分散型アプリケーションを構築できるようにするブロックチェーン プラットフォームとスマート コントラクト言語を構築しています。Kwil を使用すると、開発者はリレーショナル モデルの柔軟性を活用して、より高性能でデータ集約型の分散型アプリケーションを作成できます。

先ほどと同じ ID ストレージの例を考えてみましょう。各レコードにキーでのみアクセスできるマップに ID レコードを保存するのではなく、Kwil を使用すると、開発者はレコードをテーブルに保存し、柔軟な SQL 構文を利用してテーブルをクエリできます。

 database user_registry; table identities { address uuid primary key, name text notnull, date_of_birth int notnull, residential_address text notnull, national_id int notnull, #country_index index(national_id) } action query_by_national_id ($id) public view { SELECT * FROM identities WHERE national_id = $id; } action query_by_dob ($dob) public view { SELECT * FROM identities WHERE date_of_birth > $dob; }

オリジナルの Ethereum スマート コントラクトでは、ID を検索して条件 (国民 ID など) に基づいてすべてのユーザーを返す方法や、特定の属性 (生年月日など) に基づいてウォレットを関連付ける方法がありませんでした。このような機能を有効にするには、コントラクトを再構築して、コストのかかるガス集約型機能を追加する必要があります。ただし、リレーショナル モデルを使用すると、開発者は再構築を必要とせずにこれらのクエリを実行できるため、追加コストをかけずにデータ操作の柔軟性を高めることができます。

たとえば、 idOS ネットワークはKwil で構築された主権ブロックチェーンであり、ユーザーと dApp がユーザーの資格情報を保存できるようにします。idOS ネットワーク上で SQL を活用すると、次のことが可能になります。

1. 複数のウォレット、資格情報、属性によって関連付けられ、取得可能なユーザー。

2. DeFi プロトコルは、ユーザーの出身地に関する集計分析を実行します。

3. どのユーザーが高リスク地域出身であるかを評価するためのステーブルコイン プロトコル。

   
   

分散型ブロックチェーン プラットフォーム上でリレーショナル モデルと SQL を有効にすると、既存の Ethereum スマート コントラクトには存在できない、根本的に新しいアプリケーションを作成できます。

結論

40 年前にコンピューティング業界に革命をもたらしたリレーショナル モデルは、今日のブロックチェーン業界に革命を起こす能力を備えています。1960 年代と 1970 年代には、インデックスとアクセス パスの依存性により、データ集約型アプリケーションにおける階層型データベースの有用性が制限されていました。今日、同じインデックスとアクセス パスの依存性により、Ethereum スマート コントラクトと、複雑なデータ モデルを備えた分散型プラットフォームを強化する能力が制限されています。ただし、リレーショナル モデルをブロックチェーンに統合し、開発者に同じ表現力豊かな SQL 方言を提供することで、新しいタイプのアプリケーションを実現できます。リレーショナル データベースがビジネス需要を加速し、コンピューターが主流に採用されるのを助けたのと同じように、ブロックチェーン プラットフォームでも同じことが可能になり、より自由で分散化された、より信頼できるデジタル世界が実現される可能性があります。