減算プロトコルの機能と資産

Author: 0xKJ | PoW 2.0 Source: X, @kernel1983

スマートコントラクトがビットコインを追加しているのであれば、碑文空間はビットコインから引いていることになります。スマートコントラクトがビットコインに追加されているのであれば、碑文スペースはビットコインから減算されていることになります。トランザクションのソートとコンセンサスはすべてのブロックチェーンに必要な部分であるため、 減算理論 はすべてのパブリックチェーンに適用することができ、Inscription Spaceは当然のことながらクロスチェーンである。

減算プロトコルを考え始めると、設計の余地が大きく広がり、EVM CALLDATAの欠点やセキュリティリスクを再考する機会にもなります。まず第一に、BRC20のような碑文は実際には "平文 "であるのに対し、CALLDATAは可読性がはるかに低い。碑文プロトコルはこの原則に従うように設計されるべきであり、ユーザーはプロトコルレベルで何をしているかを知ることができます。

私たちが考える2つ目のポイントは、スマートコントラクトのパラダイムです。スマート・コントラクトによって、各ブロックチェーン・アプリケーションは、データとコードを定義するための独自の領域を持つことができます。ユーザー資産はデータであり、コードは転送、造幣、承認など、データを操作することができる。USDTのような一般的に使用される契約では、コードは実際に時間をかけて、数え切れないほどの人々の目によって検証されている。しかし、ブロックチェーン上には何千ものアセットがあり、そのほとんどがERC20標準に従っているにもかかわらず、標準の実装は必須ではない。初期のころは、セキュリティ上の大きな問題があったため、多くの契約は単に破棄された。エンジニアが経験を積むにつれて、大きなセキュリティ問題は少なくなってきたが、それでもユーザーがすべてのスマート・コントラクトを自力で監査することは不可能である。この現象の背後にある本質について考えてみると、実は、スマートコントラクトでは、発行者がコントラクトのすべてのコードをカスタマイズすることができ、既存のコードを直接再利用することはほとんどない（再利用もコピー＆ペーストによって行われる）ため、オンチェーンセキュリティの仮想的な暗い森を作り出しているからなのです。

減算プロトコルの設計は、プログラミング言語の基本要素である関数functionを、ブロックチェーンの基本要素である資産assetの概念から分離することで、これを解決しようと試みている。スマートコントラクトでは、コントラクトコードがコントラクトアセットを扱うのに対し、減算プロトコルでは、関数がアセットを操作する権限を持つ。例えば、transferはすべてのアセットにアクセスできるため、アセットごとにすべてのコードを書き換える必要がなくなる。ミント法では、より高度な定義の自由度が要求され、ミーム資産に対するミントのロジックは、USDT資産に対する方法のロジックとは必然的に異なるため、特定の[asset]_ミント関数を記述する必要があります。

さらに、関数にはrequire属性があり、関数が依存する他の関数をより静的に指定し、呼び出しプロセス中に呼び出し関数が操作できるアセットの種類をより慎重に限定して、セキュリティを向上させます。

3つ目のポイントは、私たちはずっとERC6551のアイデアが好きだったのですが、6551はERC20よりも後に登場したため、ERC20はすべてNFTに資産をバインドすることができず、イーサネットアドレスによってのみ保持することができます。アドレスは公開鍵のようなもので、秘密鍵と1対1で結びついている。仮に秘密鍵が安全でなくなったと疑って、秘密鍵を変更しようとすると、アドレス（ユーザー名）も同時に変更しなければならない。Etherでアドレスを変更する場合、ユーザーはすべての資産を新しいアドレスに移す必要があり、それにはかなりのガスコストがかかる。そのため、ユーザーが秘密鍵を変更する際のセキュリティコストは高くなると考えています。

減算型プロトコルでは、資産を「名前」で保持できるようにすることで、アドレスに紐付けられるプロトコル設計を改善できます。そのため、秘密鍵を変更しても「名前」を変更する必要がなく、秘密鍵を頻繁に変更するコストを削減できる。

私たちは、減算理論 >に導かれたクロスチェーン署名空間である減算プロトコルの設計と実装を進めています。私たちの進歩は非常に前向きで、マイナス理論からマイナス・プロトコルへのデモ実行にはわずか1週間しかかかりませんでした。

テストランは近いうちに完了する予定です！ご期待ください。

ご期待ください。