世界的なインターネット革命は、否定できないデジタル化の波をもたらし、現在、ブロックチェーン技術の台頭により所有権の概念そのものにまで広がりを見せています。 インターネットの時代から次の時代、Web2 から Web3 への移行を乗り越えるにつれて、ユーザーとの摩擦は激化するばかりのようです。 ブロックチェーンの相互作用は依然として複雑かつ原始的です。 特にアカウント管理とログインに関してセキュリティと使いやすさが不足しており、多くの人が暗号通貨分野に参入することを妨げています。
アカウント抽象化は、人々がスマートコントラクトを自分のアカウントとして使用し、ウォレット管理のための独自の柔軟なルールを設定できるようにするブロックチェーン対応テクノロジーであり、この摩擦を軽減し、暗号通貨分野で強化されたユーザールールとセキュリティ対策を浸透させる重要な約束です。
この記事では、アカウントの抽象化の概念を詳しく掘り下げ、それがブロックチェーン テクノロジーの将来をどのように支えることができるかを探ります。
外部所有アカウント (EOA): ブロックチェーンの初期原理
「アカウント抽象化」テクノロジーを完全に理解するには、一般的に「外部所有アカウント」(EOA)と呼ばれるものに根ざした、ブロックチェーン実装の初期パラダイムを把握する必要があります。
EOA は、ユーザーが暗号化キーのペア (アドレスを作成するための公開キーと、所有者がアカウントを制御できるようにする秘密キー) を生成するように動作します。 EOA フレームワーク内では、署名者とアカウントは同じエンティティです。 キーのペアが生成されると、ユーザーはトランザクションを実行するためのデジタル署名を計算することでアドレスの所有権を証明します。 分散型コンセンサスは、署名が正しいこと、および指定されたアドレスに対応する秘密キーを使用して実際に計算されたことを検証することで、これらのトランザクションを検証します。
EOA は、ビットコインとイーサリアムの元の設計の中核です。 かなり初歩的な内容にもかかわらず、 このメカニズムは、ユーザーの仮名ネットワークが許可のない環境で価値を転送するのに非常に効率的です。。 ただし、ガバナンス、回復メカニズム、またはより一般的なコード実行などの拡張機能の実装に関しては、その設計が制限されています。
一部の主要なブロックチェーン プロトコルは、すでにそのような使用例を備えています。
ビットコインの場合:
ビットコインには、アカウントと対話するときにそのプロトコルがオンチェーンルールを強制できるようにする限定された(意図的な)プログラミング言語があります。 たとえば、ビットコインのスクリプト言語を使用すると、ユーザーはユーザーの UTXO (未使用のトランザクション出力) に対して支出ルールを適用するマルチシグ ウォレットを作成できます。
さらに、タイムロックも実装できます。 たとえば、ビットコインでは、次の図に示すように、次のルールを実装するマルチシグ ウォレットを作成できます。
- 特定のウォレットには 3 人の署名者が登録されています。
- 資金を移動するには 2 つのうち 3 つの署名が必要です。
- 特定のブロックの前に資金を移動することはできません。
ビットコインの一連のルールとスクリプト言語はある程度制限されているかもしれませんが、依然として、 雷ネットワーク.
イーサリアムの場合:
イーサリアムでは、当初のビジョンが 分散型のトラストレス コンピューティング マシン。 ビットコインとは対照的に、言語セマンティクスはチューリング完全であり、オンチェーンで実行され信頼できるコンピューティングを提供する任意のプログラム (スマート コントラクト) の実行を含め、あらゆるものを簡単に計算できます。 これらのスマート コントラクトは、自動マーケット メーカー (AMM) などの強化された設計や驚くべきイノベーションも可能にします。 ただし、イーサリアムの言語は決定不可能性の問題を引き起こしますが、それはまた別の話です。
イーサリアムの設計の主な制限の XNUMX つは、すべてのスマート コントラクトの実行が EOA から開始されなければならないという事実です。 たとえば、ブロックごとにそれ自体を実行するスタンドアロンのスマート コントラクトを作成することは不可能です。 これを行うには、トランザクションをトリガーし、各ブロックでガス実行の料金を支払う EOA が必要になります。
オンチェーン スマート コントラクトの実装: いくつかの興味深いアイデア
オンチェーンガバナンスのための洗練されたスマートコントラクト設計の活用は、すでにさまざまな方法で実装されています。
Gnosis Safe: 最小限のガバナンス レベルのオンチェーン マルチシグ:
Gnosis Safe などの暗号プラットフォームは、ユーザーがアカウントに対して最小限のガバナンス ルールを設定できるオンチェーン マルチシグを提供するという点で素晴らしい仕事をしました。
Gnosis Safe を使用すると、複数の当事者が共同でイーサリアム ウォレットを管理し、トランザクションの実行前に最小限の署名や承認を要求するなど、トランザクションのカスタム ルールと条件を設定します。 さまざまな署名者は、好みに応じてセキュリティ設定をカスタマイズできます。 たとえば、毎日の支出制限を設定したり、セキュリティを強化するためにハードウェア ウォレットの統合を有効にしたり、特定のトランザクションに対して複数レベルの認証を要求したりできます。 これらのスマート アカウントは、有効なオンチェーン署名を発行し、スマート コントラクトに保持されているトークン トランザクションをトリガーする複数の EOA によって制御されます。
しきい値署名スキーム (TSS): 最小限の手数料でのオフチェーン ガバナンス:
最近の暗号研究では、ガバナンスの複数承認部分をオフチェーンで実装するために、しきい値署名スキーム (しきい値署名スキーム (TSS) またはマルチパーティ コンピューテーション (MPC) とも呼ばれます) の作成に取り組みました。
このアイデアには興味深い利点があります。 特に、EOA モデルと直接互換性があり、手数料が最小限に抑えられます。
楕円曲線デジタル署名アルゴリズム (ECDSA): 安全ですが、強力な欠点があります。
イーサリアムとビットコインのブロックチェーンは、トランザクションに楕円曲線デジタル署名アルゴリズム (ECDSA) 署名スキームを使用します。
ただし、Schnorr の署名とは異なり、ECDSA は DLP の困難さとランダムな Oracle モデルの下でも安全であることが証明されています。 さらに、ECDSA はしきい値署名スキームをネイティブにサポートするように作成されていないため、不格好な設計になってしまいます。 より具体的には、他の署名スキームの署名集約は安全であることが証明されていますが、ECDSA の署名集約は安全ではありません。 ECDSA 上のしきい値署名スキームの方程式はハッキングされており、定期的に実装上の問題が発生します。 最後になりましたが、現在、安全なエンクレーブで実行されている TSS スキームは存在しないため、危険なセキュリティ トレードオフが発生します。
アカウントの抽象化: 真のゲームチェンジャー暗号通貨のニーズ?
「アカウントの抽象化」の概念によってもたらされた大きな目新しさは、ウォレットとその周囲のガバナンス ルールを実装するためにオンチェーン スマート コントラクトを使用することです。 これらのアイデアは、Argent を含む複数のスマート コントラクト アカウント、または Gnosis などのオンチェーン マルチシグによる最小限のガバナンスですでに実装されています。
過去数か月から数年にわたって、この分野では多くの進歩が見られ、いくつかの標準化の試みが試みられてきました。 最近の注目を集めた標準は、ERC-4337 として知られています。 この標準は、所定の柔軟なガバナンスを備えたさまざまなタイプの操作を実装するための包括的なフレームワークを提供します。
より具体的には、ERC-4337 は、EOA ブロックチェーン コンテキストでのアカウント抽象化の実装に関する次のような技術的特殊性を解決します。
- 操作の意図。
- 動作検証。
- 実行と手数料の支払い (イーサリアムでは、すべての操作は手数料を支払う EOA によってトリガーされることに注意してください。そのため、ERC4337 は、ユーザーが実行する予定の操作の実行をトリガーするための、分散型バンドラーに対するインセンティブ フレームワークを提供します。)
- nonce は、EOA 向けに増分されたアンチ リプレイ メカニズムであり、ここではより洗練されたものになります。
ガバナンスに関しては、特定の操作を完了するためにさまざまな署名者とクォーラムを作成することができます。 概略的には、ユーザーはスマート コントラクトと対話し、スマート コントラクトはガバナンス ルールが満たされているかどうかを検証し、最終的に操作を実行します。
ガバナンスの検証も同様に複雑になる可能性があります。 このロジックをチューリング完全言語を使用してオンチェーンで実行する利点の XNUMX つは、任意のガバナンス ルールを作成し、任意のアルゴリズムの署名検証を実装できることです。 上で述べたように、ECDSA スキームには多くの制限があります。第一に、署名集約 (MPC / TSS) には適していません。第二に、モバイルの安全なエンクレーブの現在の実装ではサポートされていません。
改善されたユーザー エクスペリエンスと柔軟なセキュリティ:
アカウントの抽象化のおかげで、スマート アカウントを使用した同じトランザクションで異なるコントラクトへの複数のアトミック呼び出しを実行できるため、一般的な DApps を操作する際の大幅な改善につながります (たとえば、ERC に対して 2 つの異なるトランザクションを送信する必要がなくなりました) -20 トークンの承認、その後のデポジット)、およびユーザーのセキュリティのため(たとえば、ENS 解決はスマート コントラクト アカウントによって直接実行できます)。
革新的な社会的回復方法への道:
アカウント抽象化は、アカウントレベルで複雑な操作を可能にすることで、ソーシャルリカバリなどのさまざまな高度なユースケースを実現できます。 このシナリオでは、ユーザーは、アクセスを失った場合に自分のアカウントへのアクセスを許可できる信頼できる保護者のグループを指定できます。 EIP 5883 とより最近の EIP 7093 は、そのような社会メカニズムを実装するための興味深い方法を概説しています。
もう一度言いますが、ユーザーはしきい値と、アクセスが失われた場合にアカウント回復プロセスを開始する一連のルールの両方を指定できます。これにより、暗号通貨におけるユーザー エクスペリエンスが根本的に向上する可能性があります。
BLS/Schnorr 署名の集約:
前述したように、ECDSA のもう XNUMX つの弱点は、しきい値署名の設計が不格好であることです。 ECDSA とは対照的に、BLS と Schnorr はしきい値署名スキームをサポートするように設計されており、これらの標準は本質的に追加的です。 簡単に言うと、強力なセキュリティが保証された複数の部分署名を追加することで、有効な署名を計算することができます。
BLS または Schnorr 署名者を実装すると、スマート コントラクトによる検証時の手数料を最小限に抑えながら、ある程度のトークン ガバナンスが可能になります (署名ごとに 4337 つの検証ではなく XNUMX つの検証)。この集約メカニズムは、EIP XNUMX 標準の一部として記述され、オプションで実装されます。
アカウント抽象化の導入の次は何でしょうか?
パスキーの場合:
アカウントの抽象化は、EOA のコンテキストにおいてソフトウェア ウォレットと直接競合します。 ソフトウェアウォレットのセキュリティモデルは非常に弱い, どのマルウェアも、その固有のインターネット接続性と、より一般的にはより広い攻撃対象領域により、ユーザーの資金を枯渇させる可能性があるためです。 SoC (システム オン チップ) ベースの設計 (スマートフォン) は非常に異質であり、すべてに安全なエンクレーブが含まれているわけではないため、ソフトウェア ウォレットはこれ以上優れた機能を発揮することはできません。
安全なエンクレーブが含まれている場合、開発者は独自のコードをロードしてイーサリアム/ビットコイン署名を実装できません。 この文脈では、ハイエンドの携帯電話に含まれる唯一のセキュリティ機能を活用することは不可能です。
アカウント抽象化ロジックを組み込むことにより、開発者は安全なエンクレーブ デジタル署名の実装にアクセスできます。 これには、パスキー標準を通じて OS レベルですぐに利用できる WebAuthn が含まれます。
署名がユーザーのパスキーから生成されるオンチェーン ルールを確立することもできます。 これらのパスキーはイーサリアムブロックチェーンで使用されているものとは異なる楕円曲線を使用しますが、署名検証はスマートコントラクト自体に実装できるため、このメカニズムは実現可能になります。
UX に関しては、ユーザーは Apple、Google、Microsoft のエコシステム内での広範な統合から恩恵を受けることができます。 また、完全なソフトウェアウォレットよりも優れたレベルのセキュリティも提供します。 さらに、スマート コントラクトは、オンチェーンでさまざまな種類のガバナンスおよびセキュリティ メカニズムを強制できます。 たとえば、各トランザクションの実行は、オフチェーンに実装され、スマート コントラクトに特定のトランザクションの実行を許可する Web3 ファイアウォールによって保護できます。 このようなメカニズムにより、ユーザーのリスク プロファイルに応じた柔軟なセキュリティ保護が可能になります。
セキュリティの面では、このような設定 (パスキー認証によるアカウントの抽象化) により、現在のモバイル ウォレットよりも優れた保証が提供されます。 最新のスマートフォンでは、Trustzone を使用してパスキーを実装できます。 それにもかかわらず、パスキー実装の現在の状況は、次の理由により満足のいくものではありません。
- パスキーはおそらく次のように実装されています フルソフトウェア Android および iOS 用モード。 彼らは、埋め込まれたセキュア要素を(まだ?)活用していません。
- スマートフォンには信頼できるユーザー インターフェイスが実装されておらず、パスキー フレームワークはユーザーが署名するときに必要な情報をユーザーに提供しないため、理解できないトランザクションに同意する可能性があります。
アカウントの抽象化と信頼のルーツとしてのハードウェア ウォレットの重要性
アカウントの抽象化の概念により、スマート コントラクト内の多様な資産のきめ細かいガバナンスが可能になります。 少額決済にウォレットを利用する場合、これらのガバナンス ルールにより、少額のトランザクションを簡単に実行できます。 逆に、より高額な取引の場合は、セキュリティのレベルを高めることが依然として最優先事項であるため、ハードウェア ウォレットが断然の選択肢となります。
たとえば、アカウントの抽象化により次のことが可能になります。
- ポケットマネー、 どのスマートフォンでもパスキーを使用して使用できます。
- より高額な取引、 すべて安全なハードウェア ウォレット署名と Web3 ファイアウォールが必要です。
- 救命とアイデンティティ管理、 ハードウェア ウォレットの署名 + パスキー + タイムロック + Web3 ファイアウォールが必要です。
これらのデバイスは妥協のないセキュリティと所有権を可能にするため、開発が継続するにつれて、ハードウェア ウォレットが信頼の基礎となるルートとして機能するこれらのガバナンス ルールを制定する必要があります。 実際、アカウントの抽象化によってセキュリティ モデルは変化しますが、ウォレット全体には依然として強力なセキュリティ保証が必要です。 ガバナンス ルールの設計は、セキュリティの観点から、特に変更の原因となるキーを保護する上で最も重要です。 さらに、アカウント抽象化レイヤーと対話できるさまざまな署名者は、自身を認証するために特定の形式のシークレット (秘密キー) を引き続き必要とします。 これらの秘密を保護し、ブロックチェーンの相互作用に同意するために必要なすべての情報をユーザーに提供することは、アカウント抽象化フレームワークであっても依然として重要です。
終わりの思考:
以前に検討したように、EOA パラダイムは依然としてある程度初歩的なものです。 対照的に、複雑なオンチェーンルールを強制するアカウント抽象化の機能は、暗号通貨ユーザーにとって根本的な変革をもたらす可能性があります。 興味深いことに、EIP 4337 に関する最近の進歩により、私たちはこの重要な変化に近づいています。
もちろん、この先にはいくつかの課題が待ち構えています。
これらの課題の 1 つは、ブロックチェーン自体がアカウント抽象化の柔軟なガバナンス モデルを実行することです。これは、通常の EOA トランザクションと比較して実行に高いコストがかかることを意味します。 イーサリアムのレイヤー XNUMX では、チェーンはあまりスケーラブルではないため、実行にはかなりのコストがかかります。 ただし、スケーラブルなレイヤー 2 では、ユーザーがレイヤー 2 のコンセンサスによって強制され、イーサリアムのレイヤー 1 に固定された複雑なガバナンス ルールを定義するアカウント抽象化がデフォルトの選択肢になる可能性があります。
もう XNUMX つの課題は、アカウント抽象化フレームワークと対話するための標準的な方法を作成する基本的な必要性です。これまでのところ、EVM チェーンに重点が置かれています。 これらの汎用ウォレットは、高い柔軟性を含む幅広い可能性を提供します。 ただし、標準化がなければ独自仕様のままになる可能性があり、その結果、大量採用が難しくなる可能性があります。
実際、このような断片化されたプロトコルの状況は望ましくありませんが、アカウント抽象化パラダイムが EVM チェーンの基本的な機能となり、EOA インタラクションがビットコインを含む他のブロックチェーン ネットワークで極めて重要な役割を果たす可能性がある未来を目撃することになるでしょう。ユーザーにとって。 また、アカウントの抽象化によって引き起こされるこれらの変化は、最終的にはブロックチェーン レベルで統合されることも予想されます。 XNUMX つ確かなことは、アカウントの抽象化はブロックチェーンの未来に属しているということです。
- SEO を活用したコンテンツと PR 配信。 今日増幅されます。
- PlatoData.Network 垂直生成 Ai。 自分自身に力を与えましょう。 こちらからアクセスしてください。
- プラトアイストリーム。 Web3 インテリジェンス。 知識増幅。 こちらからアクセスしてください。
- プラトンESG。 自動車/EV、 カーボン、 クリーンテック、 エネルギー、 環境、 太陽、 廃棄物管理。 こちらからアクセスしてください。
- プラトンヘルス。 バイオテクノロジーと臨床試験のインテリジェンス。 こちらからアクセスしてください。
- チャートプライム。 ChartPrime でトレーディング ゲームをレベルアップしましょう。 こちらからアクセスしてください。
- ブロックオフセット。 環境オフセット所有権の近代化。 こちらからアクセスしてください。
- 情報源: https://www.ledger.com/blog/how-account-abstraction-could-impact-the-crypto-landscape
- :持っている
- :は
- :not
- :どこ
- 17
- 7
- a
- できる
- 上記の.
- 抽象化
- アクセス
- 従った
- アカウントの抽象化
- アカウント管理
- アカウント
- 実際に
- 追加
- NEW
- さらに
- 住所
- アドレス
- 養子縁組
- 高度な
- 利点
- 凝集
- 先んじて
- アルゴリズム
- すべて
- 緩和する
- 許す
- 許可
- ことができます
- 既に
- また
- AMM
- an
- 固着
- および
- アンドロイド
- 別の
- 予想する
- どれか
- 何でも
- Apple
- 承認
- 承認
- 建築
- です
- AREA
- Argent
- 周りに
- 記事
- AS
- 資産
- At
- 攻撃
- 試みた
- 認証
- 認証
- 自動化
- 利用できます
- ベース
- BE
- になる
- になる
- き
- さ
- 所属
- 以下
- 恩恵
- 利点
- より良いです
- Bitcoin
- ビットコインとエーテル
- ブロック
- ブロックチェーン
- ブロックチェーンネットワーク
- ブロックチェーン技術
- ブロックチェーン
- 両言語で
- もたらす
- 広い
- 焙煎が極度に未発達や過発達のコーヒーにて、クロロゲン酸の味わいへの影響は強くなり、金属を思わせる味わいと乾いたマウスフィールを感じさせます。
- by
- コール
- コール
- 缶
- 容量
- 場合
- 例
- 一定
- チェーン
- チェーン
- 挑戦する
- 課題
- 変更
- チップ
- 選択
- クローザー
- コード
- comes
- 一般に
- 比べ
- 互換性のあります
- コンペ
- コンプリート
- 複雑な
- 包括的な
- 計算
- 計算
- コンピューティング
- コンセプト
- 条件
- 接続性
- コンセンサス
- 同意
- その結果
- 含む
- 含まれている
- コンテキスト
- 続ける
- 縮小することはできません。
- 契約
- 逆に
- コントラスト
- コントロール
- 制御
- 逆に
- 基本
- 正しい
- 対応する
- 高額で
- コスト
- 可能性
- コース
- 作ります
- 作成した
- 作成
- 重大な
- クリプト
- 暗号ランドスケープ
- 暗号空間
- 暗号ユーザー
- 暗号
- 暗号
- 電流プローブ
- 現在
- 曲線
- カスタム
- カスタマイズ
- daily
- 危険な
- DApps
- 分権化された
- デフォルト
- 定義します
- 掘り下げる
- 保証金
- 記載された
- 設計
- 設計
- デザイン
- にもかかわらず
- 開発する
- 開発者
- Devices
- DID
- 異なります
- 難しさ
- デジタル
- デジタル化
- 直接
- 直接に
- 明確な
- 異なる
- do
- そうではありません
- すること
- ドント
- ドレイン
- 欠点
- ドリブン
- 原因
- 各
- 緩和する
- 使いやすさ
- 簡単に
- 生態系
- 効率的な
- EIP
- 素子
- 楕円
- 埋め込まれた
- 力を与える
- enable
- 可能
- 有効にする
- 飛び地
- end
- 強制します
- 強化された
- ENS
- 入る
- エンティティ
- EOA
- 方程式
- 時代
- ERC-20
- ERC-4337
- 特に
- 本質的に
- 確立する
- イーサリアム
- エテリアムブロック鎖
- エテリアルウォレット
- イーサリアムの
- さらに
- イベント
- 最終的に
- EVM
- 例
- 実行します
- 実行する
- 実行
- 体験
- 探る
- 調査済み
- 実際
- 遠く
- 特徴
- 特徴
- 費用
- 少数の
- フィールド
- 最後に
- ファイアウォール
- 名
- 柔軟性
- フレキシブル
- 焦点を当て
- フォロー中
- フォーム
- 断片化して
- フレームワーク
- フレームワーク
- 摩擦
- から
- フロント
- フル
- 完全に
- ファンド
- 基本的な
- 資金
- さらに
- 未来
- ゲームチェンジャー
- GAS
- 一般に
- 生成された
- 生成
- 与えられた
- 与える
- グローバル
- 霊知
- グノーシスセーフ
- でログイン
- ガバナンス
- ガバナンスモデル
- 助成金
- 素晴らしい
- グループ
- 保証
- ガーディアン
- 持っていました
- Hardware
- ハードウェアの財布
- ハードウェア財布
- 持ってる
- 持って
- 高められた
- ヒーロー
- こちら
- ハイ
- 彼の
- 保持している
- 認定条件
- しかしながら
- HTML
- HTTPS
- i
- アイデア
- 考え
- アイデンティティ
- アイデンティティ管理
- 影響
- 実装する
- 実装
- 実装
- 実装
- 実装
- 実装する
- 重要性
- 不可能
- 改善します
- 改善されました
- 改善
- in
- その他の
- 誘因
- 含ま
- 含めて
- 組み込む
- 信じられない
- 信じられないほど
- 確かに
- 情報
- 固有の
- 初期
- 開始する
- イノベーション
- 革新的な
- を取得する必要がある者
- 統合された
- 統合
- 予定
- 意図
- 対話
- 相互作用
- 相互作用
- 相互作用
- 興味深い
- インタフェース
- インターネット
- に
- iOS
- 問題
- 発行
- IT
- ITS
- 自体
- ジョブ
- ただ
- キー
- キー
- 既知の
- 欠如
- 風景
- 言語
- 姓
- 層
- 主要な
- リード
- 最低
- 元帳
- レベル
- レベル
- 活用します
- リー
- 可能性が高い
- 制限
- 限定的
- 制限する
- 制限
- 負荷
- ロジック
- より長いです
- 失う
- 損失
- たくさん
- 製
- メイン
- 主要な
- メーカー
- 作成
- マルウェア
- 管理
- 多くの
- 市場
- マーケットメーカー
- 質量
- 大量採用
- 最大幅
- 五月..
- 手段
- 措置
- メカニズム
- メカニズム
- 言及した
- 会った
- メソッド
- 少額決済
- Microsoft
- 最小限の
- 最小化する
- 最小化
- 最小
- モバイル
- モード
- モダン
- お金
- ヶ月
- 他には?
- MPC
- マルチパーティ
- の試合に
- マルチシグ
- しなければなりません
- ナビゲート
- ナビゲート
- 必要
- 必要
- ニーズ
- ネットワーク
- ネットワーク
- 次の
- いいえ
- ノベルティ
- 今
- 数
- of
- 提供
- on
- オンチェーン
- かつて
- ONE
- の
- 業務執行統括
- or
- オラクル
- オリジナル
- OS
- その他
- でる
- アウトライン
- 出力
- が
- 全体
- 自分の
- 所有している
- 所有者
- 所有権
- ペア
- 足
- パラダイム
- 最高の
- 部
- 特定の
- パーティー
- パスキー
- 過去
- path
- 支払い
- 国
- のワークプ
- 以下のために
- 実行する
- 実行
- 勝手に
- 視点
- 携帯電話
- 極めて重要な
- プラットフォーム
- プラトン
- プラトンデータインテリジェンス
- プラトデータ
- プレイ
- プレンティ
- の可能性
- 可能
- プ
- 前に
- プリミティブ
- 原則
- プライベート
- 秘密鍵
- 秘密鍵
- 問題
- プロセス
- プロフィール
- プログラミング
- プログラム
- 進捗
- 約束
- 所有権
- 保護
- プロトコル
- おそらく
- 受験する
- 提供します
- は、大阪で
- 提供
- 公共
- 公開鍵
- 目的
- ラジカル
- 根本的に
- ランダム
- 範囲
- リアル
- 実現する
- 本当に
- 理由は
- 最近
- 回復
- に対する
- 登録された
- レギュラー
- 残る
- 残っている
- 覚えています
- 必要とする
- 研究
- 解像度
- 責任
- 革命
- 上昇
- リスク
- 職種
- ルート
- ルーツ
- ルール
- ルール
- ラン
- ランニング
- 安全な
- 保護
- 同じ
- 節約
- ド電源のデ
- シナリオ
- スキーム
- スキーム
- シュノール
- 秘密
- 安全に
- セキュア
- セキュリティ
- セキュリティー対策
- と思われる
- つかむ
- 送信
- サービング
- セッションに
- 設定
- いくつかの
- シフト
- すべき
- 示す
- 符号
- 署名
- 重要
- 単に
- から
- スマート
- スマート契約
- スマート契約
- スマートフォン
- スマートフォン
- So
- これまでのところ
- 社会
- ソフトウェア
- 解決する
- 一部
- 幾分
- 洗練された
- スペース
- 特定の
- 特に
- 支出
- 費やした
- 広がる
- スタンドアロン
- 標準
- 標準化
- 規格
- まだ
- ストーリー
- 強い
- そのような
- サポート
- サポート
- 支援する
- 表面
- 技術的
- テクノロジー
- テクノロジー
- より
- それ
- 未来
- アプリ環境に合わせて
- それら
- 自分自身
- その後
- ボーマン
- 彼ら
- もの
- この
- しかし?
- しきい値
- 介して
- 〜へ
- トークン
- あまりに
- 牽引力
- トランザクション
- トランザクションの実行
- 取引
- 転送
- 遷移
- 試験
- トリガー
- トリガ
- トリガー
- 信頼
- 信頼されている
- 信頼できない
- チューリング
- 順番
- 典型的な
- 紛れもない
- 下
- 支え
- わかる
- us
- つかいます
- 中古
- ユーザー
- 操作方法
- ユーザーインターフェース
- users
- 活用
- ux
- 値
- さまざまな
- Verification
- 検証する
- 非常に
- ビジョン
- 財布
- 財布
- ました
- ウェーブ
- 仕方..
- 方法
- we
- 弱点
- Web2
- Web3
- WELL
- この試験は
- いつ
- かどうか
- which
- while
- 誰
- ワイド
- 広い範囲
- より広い
- 意志
- 以内
- 無し
- 目撃者
- 働いていました
- 作品
- でしょう
- 年
- まだ
- You
- ゼファーネット