スマートコントラクトとは何ですか？なぜ必要なのですか？
かなり前に、最初の複製されたステートマシンであるビットコインが登場した後、人々はコンセンサスに組み込まれた機能が制限されすぎていることに気付き始めました。 暗号化コードを取引に追加するのではなく、非常に実際の使用法について話します-各ドメインが集中レジストラではなく公開鍵に属するDNS、あらゆる種類のトークンと金融派生物（ビットコインを所有するように共有を所有するため）、オンチェーン交換（取引所への信頼を伴わない大量の取引）、支払いチャネル（一般にトランザクションメッセージのオーバーヘッドなしで2つのアカウント間で一般的なエスクローを迅速に再配布します）...
関数を追加するには3つの方法がありました。
1）最も明白なのは、それらをネイティブにブロックチェーン自体のコードに入力することです。
ブロックチェーンは本質的に複製されたウェブサイトですが、ウェブサイトに十分な機能がない場合、何をしていますか？ 新しいモデルまたはコントローラーとしてコードに直接追加するだけです。 しかし、分散ネットワークの場合、モデル/コントローラーのそのような変更のためのプロセスはありません-結局、それは彼らの利点に使用することができます。 チャット/フォーラムで同時に全員が同意するハードフォークオプションのみ。
2）この機能を使用して別のブロックチェーンを作成します。
そのため、複数の「1つのアイデアのブロックチェーン」ala namecoinで起こりました。 人々が1つの機能に新しいネットワークを使用することを望まず、相互運用性も必要であり、多くのことが相互に依存していることがすぐにわかりました（ローン、ID、および資産自体が同じアドレス空間に住みたい）
3）内部仮想マシンとオペコードを使用して機能を実装する。
Satoshiでさえ、更新の問題のためにBitcoinにスクリプトを配置しました。これは多くのことを可能にしましたが、十分ではありませんでした。 したがって、放送によって拡張スクリプトが提案され（現在は完全なチューリング）、それを使って（理論的には）何でもできると言われています。
そのため、スマートコントラクトと呼ばれるブロックチェーン内の仮想マシンによって実行されるコードであり、新しい機能を実装するために必要です。 「オペコードパッチ」と呼ぶことができますが、あまり売れていません:)
スマートアップデートとは何ですか？
過去数年間、スマート契約に目を向けると、期待に応えられなかったことが明確に言えます。 はい、ビットコインではICOブームは不可能でしたが、erc20トークンのみに高度なEVMを導入するのは多すぎました。
堅牢性の小さな「パッチ」を書くことは非常に困難です。 一番下のレベルでは、オペコードが非常に少ない（設計上）生のVMと単純なキーと値のデータベースがあります。 すべての操作は非常に高価（ガス代）であり、まったく好転することはできません。
洗練されたユーザーケースはほとんど不可能です。 Ryden github.com/raiden-network/raiden-contracts/tree/master/raiden_contracts/contracts-複雑な金融システムを管理するための生のエイリアン言語（ 堅牢性 ）の数千行のコードをご覧ください。 単純な攻撃によるパリティおよびDAOハッキングがいくつか見られましたが、このような巨大なコードベースではどのような攻撃が待っていますか？
SQLデータベースはありません。NoSQLは存在しません。グラフデータベースも計画されていません。 キー反復、多対多？ ORM？ これは契約内には存在しません。 ティリングも、よく知られているプログラミング言語に比べて非常に弱いです。
現代の堅牢性プロジェクトの作業の95％は、厳密には堅牢性との戦いであり、コードのアーキテクチャではありません。 同じ考えをjavascriptで10倍高速かつ信頼性の高い方法で実装できます。これは、javascriptを知って記述できるため、堅牢性エコシステムがBrainfuckエコシステムよりもはるかに進んでいないからです。
EVMを守るために、私はまだ言います。ビットコインの世界の状況は、チューニングがさらに弱く、オペコードがさらに小さいため、さらに悲惨です。 Lightning開発者は噛みついていますが、まだサボテンがあります-Bitcoinの双方向ビットコインチャネルの複雑さは非常にクレイジーであるため、コードベースの維持はさらに難しく、状態チャネル内のスプライトや複雑なロジックなどの便利なことはまったく不可能です。
オンチェーンガバナンス=スマートアップデート
堅実に悲しみを食い尽くしたので、2012年に戻って、ブロックチェーンにネイティブにユーザーケースを追加して破棄された最初のオプションを思い出しましょう。
多くの人が気づいているように、EVMの実装後、EVM自体は想定どおりに更新を停止しませんでした（基本レベルは変更されず、新しいコード全体はEVM内にのみあります）-それどころか、 Ethereumの独裁制で定期的に分岐します。
つまり プロファイルにのみ同じ卵。 人々のグループは、自分の手でオンチェーンレイヤーを変更する方法を決定し、コードをgithubに配置します。すべてのユーザーは、新しいコードをダウンロードするしかありません。 「ハードフォークは金曜日に予定されています。すぐにアップグレードしてください」と彼らは言います。
この形式では、スマートコントラクトのアイデアは絶対に失敗です-コンセンサスレイヤーの動作を決定する権限が既にあります（イーサリアムのgithubアカウント）。メインレイヤーの更新を取り除くことができなかった場合、余分で効果のない抽象化は何のためですか？
更新を取り除くことができないため、少なくともこのメインレイヤーを可能な限り分散化して更新する方法を考えましょう。
ソフトウェアパッチをブロックチェーン内で提供し、バリデーターが投票することができます。また、一定期間が経過すると、全員に同期してパッチが簡単に実装されます。 この「オンチェーンガバナンス」の考え方はかなり前から存在していましたが、誤解しない限り、Tezosがそれを最初に説明しました。 テゾが見失ったのは、オンチェーンガバナンスがスマートコントラクトの直接的な競争相手であるということです（そのため、スマートアップデートと呼びます）。
スマート更新がある場合は、スマートコントラクトは必要ありません。 ユーザーケースは、選択したデータベース（SQL / NoSQL /何でも）、プログラミング言語（マシンレベルで既にコードを実行し、何にも限定されない）で、より速く、より良く実装できます。 完全な自由、あなたが堅実性に費やした95％のオーバーヘッドを差し引いたものであり、新しいブロックチェーンをソリューション＃2として彫る必要はありません。
スマートアップデートには正確に2つのマイナスがあります
1.現在、すべてのユーザーケースがバリデーターによって承認されるわけではありません。なぜなら、どの種類のパッチがネットワークに役立つかを考え、投票するからです（そして、率直に言って悪意のあるバックドアを遮断します）。 暗号通貨のようなものは、大多数によって承認されることはほとんどありません（67％または95％のゴミ箱、ネットワーク自体の内部で構成されます）
2.バリデーターは、この力を使用して、直接有益なパッチをプッシュします（好ましくないユーザーを削除し、3つのボックスからアセットを取得します）。 この問題を解決するために、遅延期間があります。 パッチが承認された後、ネットワーク全体で2〜6週間の学習期間があります。 一般のユーザーがそれを好まない場合、人々は集まり、ハードフォークを作成し、バリデーターのセットをより適切なものに置き換える（または最悪の文字を捨てる）必要があります。
怖いように聞こえますが、 今はすでに機能しています -イーサリアムgithubは絶対に任意のハードフォークを提供できます。これは、ユーザーが何かを気に入らない場合に独裁をリセットするというタスクです。 悪化することはありません。 githubリポジトリの形式の最初のチャネルを持つ既存の「シャドウ」政府の代わりに、このプロセスを単純化して、各開発者/検証者に透明なステーキを提供します。
まとめ
したがって、EVMスマートコントラクトは興味深い概念であり、新しいユーザーケースの問題を解決するためのスマートな更新のための透過的なメカニズムを実装することだけが必要な場合に、失敗、間違った方向への過度の転換であることが判明しました。
未来はスマートな更新であり、現在開発中のほとんどすべてのブロックチェーンには、最初からそれらが含まれています（tezos、dfinity、polkadot、decred、tendermint、fairlayerなど）。 スマートコントラクト自体でさえ、彼らは現在、内部で更新メカニズムを有効にしようとしています。これは、固定設定の概念が機能しないことを認識しており、遅かれ早かれ更新する必要があります 。
このトピックに関する詳細なwiki （英語）です。VitalikとVlad Zamfirがスマートアップデートを非難していることに驚かされます 。彼らの直接のライバルはEVMを完全に時代遅れにしています。