@Dusk
スマートコントラクトを学べば学ぶほど、「誰かがボタンを押さなくても実行できるのか」という難しい問いが、難問ではないように思えてきます。
本当の難しい問いは、コードが設計どおりに完全に動作したとき、何が起きるのか――そして、その設計が間違っていた場合です。
DUSKはDuskVMを通じてスマートコントラクトの実行をサポートしており、コントラクトはプログラムされた論理に従って入力を処理します。
これにより、責任のあり方が微妙に変わります。
手動のトランザクションであれば、人は止まって考え直したり、進行を拒否したりできます。自動化では、その判断をシステムにあらかじめ組み込めてしまいます。条件が満たされれば、実行が起こるのです。
つまり、テストは単に開発者の責任だけではありません。それは信頼のモデルの一部になります。
これは、DUSKにとってさらに重要です。DUSKのアーキテクチャは、アクセス、送金、開示、決済が実行可能なプロセスと相互作用し得る、合理化された金融ワークフローのために設計されています。
失敗したコントラクト呼び出しは実行エラーとして記録できますが、失敗を記録することと、その結果として誰が責任を負うべきかを決めることは同じではありません。
だから私は、自動化の本当の課題は「人間をトランザクションから取り除くこと」ではないと考えています。
コードが最終判断を下す前に、人間の責任がどこに属するのかを決めることです。
自動化された金融が、欠陥のある判断を、まさに正確に実行してしまったとき、最終的にその誤りを負うのは誰なのでしょうか?
#dusk $DUSK #Dusk #GrowWithSAC
スマートコントラクトを学べば学ぶほど、「誰かがボタンを押さなくても実行できるのか」という難しい問いが、難問ではないように思えてきます。
本当の難しい問いは、コードが設計どおりに完全に動作したとき、何が起きるのか――そして、その設計が間違っていた場合です。
DUSKはDuskVMを通じてスマートコントラクトの実行をサポートしており、コントラクトはプログラムされた論理に従って入力を処理します。
これにより、責任のあり方が微妙に変わります。
手動のトランザクションであれば、人は止まって考え直したり、進行を拒否したりできます。自動化では、その判断をシステムにあらかじめ組み込めてしまいます。条件が満たされれば、実行が起こるのです。
つまり、テストは単に開発者の責任だけではありません。それは信頼のモデルの一部になります。
これは、DUSKにとってさらに重要です。DUSKのアーキテクチャは、アクセス、送金、開示、決済が実行可能なプロセスと相互作用し得る、合理化された金融ワークフローのために設計されています。
失敗したコントラクト呼び出しは実行エラーとして記録できますが、失敗を記録することと、その結果として誰が責任を負うべきかを決めることは同じではありません。
だから私は、自動化の本当の課題は「人間をトランザクションから取り除くこと」ではないと考えています。
コードが最終判断を下す前に、人間の責任がどこに属するのかを決めることです。
自動化された金融が、欠陥のある判断を、まさに正確に実行してしまったとき、最終的にその誤りを負うのは誰なのでしょうか?
#dusk $DUSK #Dusk #GrowWithSAC
Code owns the error
100%
Users own the error
0%
Shared responsibility
0%
3 投票 • 投票は終了しました

