What Is a Smart Contract—and Why Its Rules Cannot Be Changed Retroactively?

Disclaimer: This article is for educational purposes only. It is not financial, legal, or investment advice.

A smart contract is often described as a “digital agreement.” That is a useful analogy, but it is not the full picture. More precisely, a smart contract is a program deployed on a blockchain that stores data and executes predefined instructions.

例えば、条件を満たした後にのみ送金を許可したり、参加者を記録したり、操作の成功後に記録を更新したりできます。誰かがトランザクションを送信すると、ネットワークがコードを実行し、結果を記録します。

最初から理解すべき二つの制限：

「Smart」は、プログラムが思考したり意図を判断したりできるという意味ではありません。
「Contract」という名称だけで、そのコードが法的な契約として扱われるわけではありません。

スマートコントラクトは、コードで許可されたとおりに動作します。ロジックにバグ、安全でない管理機能、誤った前提が含まれていても、ブロックチェーンが自動的に修正することはありません。

要点

スマートコントラクトは、ブロックチェーンアドレスに保存されたコードとデータです。

ネットワークがあらかじめ定義されたルールに従って機能を実行します。

確定した操作を後から単純に書き換えることはできません。

一部のコントラクトは、調整可能なパラメータやアップグレード可能なロジックを備えて設計されています。

ユーザーはコントラクトアドレスだけでなく、そのロール、権限、アップグレードの仕組みも確認する必要があります。

スマートコントラクトを簡単に理解する方法

自動化された保管ロッカーを想像してください。

ルールには「受取人は指定日以降にのみロッカーを開けることができる」と記載されています。
送信者が資産を入金します。
受取人が指定時刻より前に開けようとすると、機械は拒否します。
指定日を迎え、その他の条件もすべて満たしていれば、同じ要求が成功します。

違いは、スマートコントラクトが一社のサーバーで実行されるのではない点です。ブロックチェーンネットワークが命令を処理し、共有される結果へ到達し、記録します。

これは、荷物が届いたか、天気がどうか、為替レートがいくらかをコントラクトが自動的に知るという意味ではありません。ブロックチェーンは利用可能なデータを基に動作します。外部世界の情報には、一般にオラクルと呼ばれる追加の情報源が必要で、結果はその情報源にも左右されます。

コード、状態、トランザクション

スマートコントラクトを理解するための三つの観点：

Code: its available functions and checks.
State: its current data, such as balances, statuses, and configuration values.
Transaction history: the sequence of operations that changed that state.

公開データを読み取るだけでは通常、状態は変わりません。トークン送金や参加登録など、状態を変更する操作にはトランザクションが必要です。ユーザーが署名し、ネットワークが処理し、通常は手数料がかかります。

トランザクションが取り込まれファイナライズされると、チェーン履歴の一部になります。コードで許可されていれば後続トランザクションで現在の状態を変更できますが、以前の記録を書き換えることはありません。両方の出来事が表示されたまま残ります。

「遡って変更できない」の正確な意味

コントラクトがアドレス A からアドレス B への 100 トークンの送金を記録したとします。確定後、管理者がそのブロックを開き、元の操作がなかったかのように 100 を 10 へ置き換えることはできません。すでに確定したトランザクションの受取人をひそかに変更することもできません。

If the code includes a refund, reversal, or compensation function, using it creates a new transaction. The blockchain will show the original action and the later response.

そのためオンチェーン履歴は独立した検証に役立ちます。異なる確認者がネットワークへ照会し、同じ一連の出来事を確認できます。

それでも、ブロックチェーンが「いかなる状況でも決して変わらない」と言うのは正確ではありません。ネットワークにはそれぞれのファイナリティモデルがあり、プロトコル障害や攻撃の影響を受ける可能性もあります。実務上の要点はより限定的です。通常の稼働状態では、ユーザーやアプリ管理者が非公開データベースの一行のように、確定済みブロックチェーン記録を編集することはできません。

それはコントラクトが決して変更されないという意味ですか？

必ずしもそうではありません。「変更不能なコントラクト」という表現は、この点でよく誤解されます。

1. アップグレード不可のコントラクト

デプロイ済みコードは元のロジックで動作し続けます。開発者は新しいアドレスへ新しいコントラクトをデプロイできますが、旧アドレスとその履歴は残ります。ユーザーは自ら新しいバージョンへ移行する必要があります。

2. パラメーターを変更できるコントラクト

コードには、上限変更、操作の一時停止、allowlist の管理、手数料受取先の更新を行う管理者機能が含まれる場合があります。これらの機能にも新しいトランザクションが必要で、コード内に存在する権限しか行使できません。

過去を書き換えるものではありませんが、将来の操作ルールを変更できます。

3. アップグレード可能なアーキテクチャ

一般的な設計ではプロキシコントラクトを使用します。プロキシアドレスは変わらず、呼び出しを別の実装コントラクトへ転送します。ガバナンスがその実装を変更できる場合、同じプロキシアドレスでも将来の動作が変わる可能性があります。

つまり、「アドレスが変わっていない」ことは、必ずしも「ロジックが一度も変わっていない」ことを意味しません。慎重なレビューでは次を確認します：

そのアドレスはプロキシですか？
誰が実装をアップグレードできますか？
署名は一つで足りますか、それとも複数必要ですか？
実行までの待機時間はありますか？
操作を一時停止できますか？
管理者が変更できるパラメータは？

例：上限の変更

日次上限が 1,000 単位のコントラクトを想像してください。

月曜日に、ユーザーが 800 単位の操作を完了します。
火曜日に、権限を持つアドレスが新しいトランザクションで上限を 500 に変更します。
月曜日の操作が消えたり、別の記録へ変わったりすることはありません。
コントラクトのロジックでそのように指定されていれば、火曜日以降は 500 単位の上限が適用されます。

ブロックエクスプローラーでは両方のトランザクションを確認できます。ただし、その結果を理解するには、呼び出された関数と、その関数に与えられた権限を把握する必要があります。

ブロックチェーンが証明できること、できないこと

パブリックブロックチェーンで確認できること：

参加アドレス。
トランザクションの時刻とステータス。
送金された資産と金額。
データが正しくデコードされた場合の呼び出し先関数。
イベントと処理の順序。
デプロイ済みバイトコードとの一致が検証されたソースコード。

Deployment on a blockchain does not by itself guarantee:

バグや脆弱性が存在しないこと。
誠実な開発者。
経済的な持続可能性。
正確な外部データ；
管理者権限が存在しないこと。
法的保護。
誤送金後の復旧。

透明性とは証拠を確認できることです。見えるものすべてが安全という意味ではありません。

操作前の実用チェックリスト

Verify the address. Obtain it from an official project source and compare it carefully.
Verify the network. The same address format may exist across several EVM networks.
Check source verification. Published source code makes analysis easier, but it is not a security audit.
Look for proxies and upgrades. Identify the implementation and the upgrade authority.
Review administrator powers. Look for owner, admin, pause, upgrade, fee, and access-control functions.
Review token approvals. Before approving, confirm the token, spender, and allowance.
Start small. For a first interaction, consider a small test amount while accounting for fees.

ユーザーの署名が重要な理由

スマートコントラクトが自動的にウォレット全体へのアクセス権を得ることはありません。特定の呼び出しを受け、付与された権限の範囲内でのみ動作します。

ただし、署名によって単純な送金以上の権限を与える場合があります。トークン使用の承認、無制限の利用許可、資産交換、NFT の移転、複雑な一連の呼び出しなどが実行される可能性があります。

ウォレットが要求内容を明確に説明できない場合、ユーザーは「ブラインド署名」のリスクに直面します。知っているチャットから届いたリンクである、または公式サイトに似ているという理由だけでトランザクションを承認してはいけません。

まとめ

スマートコントラクトは約束でも、公平性を魔法のように保証するものでもありません。コード化されたルールを実行し、検証可能な履歴を残すプログラムです。

A confirmed operation cannot be quietly edited after the fact. However, future parameters or logic may be changeable if the architecture was designed that way. The most useful question is therefore not only “Is there a smart contract?” but also: “What does its code allow, and who can influence how it works in the future?”

要点