HemiがどのようにビットコインとスマートコントラクトをhVMとトンネルベースの実行を通じて結びつけるか

@Hemiに興味を持ったのは、どれだけ多くの暗号通貨プロジェクトがビットコインとスマートコントラクトのブリッジについて語っているにも関わらず、ラップトークン、別のオラクル、または第三者リレイヤーに依存していることに気づいたからです。Hemiが主張していることは私の注意を引きました：それは、EVMのような環境にネイティブビットコインの認識を埋め込むことで、スマートコントラクトがビットコインの状態と資産を直接参照できるようにするというものです。その考え — ビットコインを単にラップするのではなく、ビットコインの状態を契約環境に持ち込むということ — は本当に大きな飛躍のように感じました。(ドキュメントを参照してください：HemiのhVMは「ビットコインの認識でアップグレードされたEVM」であり、埋め込まれた「Tiny Bitcoin」デーモンを介しています。) $HEMI を使用して、トンネルのアイデアを実験しました。Hemiは「橋」ではなく「トンネル」を提示します — 微妙な違いは、トンネルがプロトコルレベルで両方のチェーンの状態を認識しているのに対し、単にラップと保管者に依存していないことです。例えば：Hemiの「ビットコイントンネル」は、ユーザーが本物のビットコイン(やビットコインネイティブ資産)をビットコインチェーン上でロックし、Hemi上で代表トークンを受け取ることを可能にします。引き換え時に、ビットコインは金庫から解除されます。実際にこれはどういう意味か：あなたはBTCを保有していて、それをスマートコントラクト、DeFi、またはEVMスタイルのdAppsで使用したい — Hemiはそれを可能にし、基盤となるメカニズムが多くの以前の橋よりもより直接的にビットコインにアンカーされることを保証します。 私がアーキテクチャを見た方法：まず、hVM。#HemiはEVM互換の仮想マシン(を実行し、Solidity契約、馴染みのあるツールチェーン)を提供し、ビットコインのフルノード(または決定論のためにインデックスされた軽量版をそのVMのランタイム内に埋め込んでいます。例えば、「Tiny Bitcoin Daemon」)TBC(はビットコインのブロックと同期し、「Processed Bitcoin View」はすべてのHemiノードで維持されるため、スマートコントラクトはビットコインから決定論的にデータを取得できます：UTXO、残高、取引確認、ブロックヘッダー。それによって、開発者ユーザーとして私に与えられたのは、次のような契約を書く能力です：特定のビットコインアドレスがXサトシを受け取った場合、この契約ロジックをHemiでトリガーします。仲介オラクルなしで。それは力強く感じました。 次にトンネル機構について：私が)ビットコイントンネルにBTCを入金したとき、システムはビットコイン側の$HEMI マルチシグまたはカストディアルシステム(にBTCをロックしました。hVMはUTXOおよびビットコインの状態を監視して入金を確認し、確認されると)いくつかのビットコインの確認後(、Hemiは「hemiBTC」または代表トークンを発行し、私はHemiのスマートコントラクト環境で使用できました。出金時には、私は代表トークンを焼却し、金庫がBTCを私に返すようにトリガーします。ドキュメントには、入金については、ユーザーがBTCを金庫に送信し、hVMがUTXOテーブルを監視し、約6回のビットコイン確認後に代表トークンが発行されるとあります。出金については、Hemiで代表トークンを焼却し、hVM + トンネルロジックが確認し、金庫が元のBTCをビットコインアドレスにリリースします。私はテストネットで小さな送金を試み、「BTC側のロック→Hemi側の発行」のフローを見ました。ユーザーインターフェースはシンプルでしたが、バックエンドアーキテクチャは簡単ではありませんでした。 私が気に入ったことの一つは、セキュリティ設計です：@Hemiはビットコインの状態をVMに直接埋め込むことで、)従来のブリッジが持ついくつかの信頼前提、例えば、完全に中央集権的なカストディアンや失敗する可能性のあるオラクル(を回避しています。Hemiはトンネルセキュリティモデルのフェーズを持ち続けています：フェーズ0では過剰担保されたマルチシグボールトを使用し、将来のフェーズではより高い分散化のためにBitVM / 1-of-N信頼モデルを使用する予定です。私にとって、それはつまり：はい、今日でも信頼コンポーネントは存在しますが、アーキテクチャは改善のために層になっています。 使用の観点から、私はその意味合いが興味深いと感じました：ビットコインを保有するあなたは、今やBTCをHemiのスマートコントラクトの世界に持ち込み、そのEVM互換性を通じて、Ethereumスタイルのエコシステムに可能性を持ち込むことができます)。あなたはBTCを担保として使用し、DeFiと相互作用し、価値を移転させ、基盤となるシステムは依然としてビットコインチェーンに証明可能な方法で結びついています。もしあなたがスマートコントラクト開発者であれば、ビットコインアドレスやトランザクションイベントを監視する契約を作成し(、hVMプレコンパイルを通じて)Hemi上でロジックをトリガーすることができます — これは以前は非常に困難でした。例えば、hVMは次のようなプレコンパイル契約を提供しています：BtcBalAddr (ビットコインアドレスの残高)、BtcUtxosAddrList (ビットコインアドレスのUTXO)、BtcTxByTxid (IDによるトランザクションの取得)。 もちろん、完璧ではありません。私が使用する中で気づいたトレードオフとオープンクエスチョンがあります。一つは複雑さです：UIはシンプルでしたが、バックエンドメカニズム(ボールト、確認時間、ミント→バーンフローが堅牢であることを保証する)ため、遅延があります(BTC確認時間)。ドキュメントによれば、デポジットには約1時間、引き出しには現在のモデルでは約12時間かかる可能性があります。また、埋め込まれたノードアクセスは強力ですが、開発者やユーザーはビットコインの状態の詳細(UTXO、アドレスなど)を理解する必要があるため、L2上のシンプルなERC-20トークンよりもやや高い技術的オーバーヘッドがあります。 別の懸念点：完全な分散化までのボールト/カストディトラスト：フェーズ0では、完全に自律的なノンカストディアル信頼最小モデルではなく、オーバーコラテライズされたマルチシグを使用したボールトを使用しています。アーキテクチャは将来のBitVM / 1-of-N信頼を約束していますが、それまでの間はリスクが残ります。スラッシングや不正行為がどのように処理されるかを調べました：ドキュメントはhVMが不正な引き出しを監視していることを示しています；悪意のあるボールト活動はユーザーによってフラグ付けされ、スラッシングが適用される可能性があります。ユーザーが争議を提起することの社交性はまだ初期段階です；そのシステムがどのように堅牢になるかをさらに観察したいと思います。 また、契約がビットコインデータにアクセスできる一方で、パフォーマンスとコストの影響が重要です：あなたはより大きなデータ (ビットコインブロック、UTXOセット)、およびノード間での状態の同期を扱っています。これは、単純なERC-20ロジックと比較してオーバーヘッドを追加する可能性があります。私のテストでは、それが過度に遅いとは感じませんでしたが、完全なメインネット使用まで判断を保留します。 要約すると、Hemiと過ごした時間の後、私はそれがビットコインとスマートコントラクトの世界の間に魅力的なブリッジを提供すると信じています — ビットコインを単にラップするのではなく、hVMとトンネル実行を介してビットコインをスマートコントラクト環境に持ち込むことによって。BTCを保有し、DeFiに参加したい暗号ユーザーとして、またビットコインの状態を必要とするスマートコントラクトを構築する開発者として、Hemiは私が見た中でより洗練されたアーキテクチャの一つです。 もし私が評決を選ぶなら：はい、Hemiは有望であり、ビットコインをプログラマブルにし、スマートコントラクトエコシステムとよりネイティブな方法で相互運用可能にする可能性について楽観的です。私が注目する重要な領域は、金庫/トンネルの信頼モデルが完全な分散化(に向けてどのように進化するか)、開発者ツールとUXがどのように改善され(技術的負担を軽減するか)、そしてどれだけの採用が行われるか(によって流動性と使用がトンネルを通じて流れるか)です。すべてが整えば、Hemiはビットコインを意識したスマートコントラクトの基礎的なレイヤーになると期待しています—ビットコインのセキュリティとEVMスタイルの多様性を橋渡しします。 #Hemi ( {スポット})HEMIUSDT$HEMI