Michelson アンチパターン
目次
マイケルソンアンチパターン[編集]
マイケルソンは、安全な契約書を作成しやすく、脆弱な契約書を書くのが難しいように設計されていますが、データや資金を漏らしているバギー契約を書くことも可能です。これは、Tezosブロックチェーンの契約書を作成したり、これらの問題を回避するコードを書く別の方法で間違いを犯したリストです。
注:現在、マイケルソンの並行性モデル(サブトランザクションの方法と時期)を改訂しているため、これらのパターンの一部は言語自体によって防止されます。
契約のリストへの払い戻し[編集]
契約の1つの共通のパターンは、一度に人々の資金のグループを払い戻すことです。これは、悪意のあるユーザーがさまざまな問題を引き起こす可能性があるため、任意の契約を受け入れると問題になります。
考えられる問題:? ?
- 1つの契約は一連のコールバックを通じてすべてのガスを呑み込む
- ブロックが満杯になるまで1つの契約書がトランザクションを書き込む
- リエントラントのバグ。マイケルソンはこれらを意図的に書くのを難しくしますが、試してもそれは可能です。
- 契約は `FAIL`命令を呼び出し、すべての計算を中止します。
代替/ソリューション: ? ?</sub>?</sub>?</sub>
- 人々のキーからデフォルトのアカウントを作成します。既定のアカウントは上記のバグを避けてコードを実行できません。契約者よりもむしろキーを提出させる
- 人々に個別に資金を引っ張ってもらう。各ユーザーは、自分の脱退だけを壊すことができます。 'これは、再入荷バグを守るものではありません。' '
ユーザーがバッチのサイズを増やすことができる場合、バッチ操作を避ける[編集]
リニアまたはスーパーリニア操作に依存する契約は、契約が燃料制限に踏み込まずに終了できなくなるまで、値を提供する悪意のあるユーザーにとって脆弱です。これはあなたの契約をデッドロックする可能性があります。
.. _possible-issues-1:
考えられる問題:? ?
悪意のあるユーザーは病理学的な最悪の場合に契約を強制し、利用可能なガスで仕上げるのを止めます。厳しいガス制限がない場合、ノードオペレータは一定量以上のガスを取る契約を実行したくないので、これは依然として無効になる可能性があることに注意してください。
- 償却されたアルゴリズムやデータ構造の遅いケースを不適切なタイミングで打つことができます。契約の利用可能なガスをすべて使い切ってください。
.. alternativessolutions-1:
代替/ソリューション: ? ?</sub>?</sub>?</sub>
- 償却された操作に依存するデータ構造やアルゴリズムは避けてください。特にユーザーがデータを追加する際には注意が必要です。
- 利用可能なガスを圧倒することのないレベルまで、契約で保管できるデータの量を制限する。
- バッチ処理を一時停止して再開できるように契約書を書いてください。これはこれらのシーケンスを複雑にし、利用可能なガスの絶え間ないチェックを必要とするが、様々な攻撃を防止する。
- 攻撃が法外に高価になると想定しないでください。*暗号化通信は頻繁に極端な価格変動があり、非常に意欲のある攻撃者は、莫大な費用が正当であると判断する可能性があります。覚えておいてください。契約を無効にする攻撃は、著者だけでなく、その契約のユーザーをターゲットにしています。
シグネチャだけではリプレイ攻撃を防ぎません[編集]
契約でメッセージを認証するために署名を使用する場合は、リプレイ攻撃に注意してください。ユーザーがデータに署名する場合、そのデータが契約の有効なメッセージではないことを確認する必要があります。あなたがこれをしないと、他の誰もあなたの契約を同じ入力で呼び出すことができ、以前の承認にピギーバックすることができます。
.. _possible-issues-2:
考えられる問題:? ?
- 以前に承認されたアクションを再生することができます。
.. alternativessolutions-2:
代替案/ソリューション ? ?? ?
- ユーザーに固有の署名を求めるデータを作成するには、内部カウンタを使用します。このカウンタは、ユーザーが承認する必要があるものを見つけるために、キーごとに設定する必要があります。これは、契約違反の再発を防ぐために、契約の署名付きハッシュとペアにする必要があります。
-
SOURCE
命令を使用して、予想される送信者がメッセージの送信元であることを確認します。
ユーザーがすべてのスマート契約 ? <subに一意のキーを使用すると仮定しないでください<サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> / sub> </sub> </sub> </sub> </sub> </sub> </sub> > </sub> </sub> </sub> </sub> </sub>
ユーザーは、相互作用するすべての契約で常に異なるキーを使用する必要があります。そうでない場合、ユーザーが別の契約書に署名したメッセージを契約に送ることができます。内部のカウンターだけではこの攻撃から保護することはできません。あなたの契約のハッシュとペアにする必要があります。メッセージの送信元を確認する必要があります。
プライベートデータの格納/転送[編集]
トランザクションのブロードキャストを含むデータが誰にでも公開されると、そのデータは公開されます。ブロックチェーンの生態系のどこからでも秘密情報を送信しないでください。その情報を含むトランザクションをブロードキャストするとすぐに、誰でもそれを見ることができます。さらに、システム内の悪意のあるノードは、署名されていないトランザクションを遅延、変更、または並べ替えることによって操作できます。
.. _possible-issues-3:
潜在的な問題 サブ>
- データに署名がない場合は、変更することができます
- 取引が遅れることがあります
- 秘密の情報が公開される
.. alternativessolutions-3:
代替案/ソリューション ? ?? ?
- 個人情報をブロックチェーンに保存したり、トランザクションでブロードキャストしたりしないでください。
- 操作された場合、悪用される可能性のある情報を含むすべてのトランザクションに署名します。
- カウンターを使用して取引注文を実施する。
これは少なくともあなたの契約に送られたメッセージに論理時計を作ります。
転送の前にすべての状態を設定しない[編集]
再入可能性はブロックチェーン上の潜在的な問題です。契約が別の契約に移転すると、その契約は独自のコードを実行し、元の契約に戻るなど、任意の追加移転を行うことができます。転送が行われる前に状態が更新されていない場合、契約は古い状態に基づいてアクションを呼び出して実行することができます。
.. _possible-issues-4:
潜在的な問題 サブ>
- 複数の出金/措置
- 状態が2回後に更新された場合、不正な状態を生成する
..alternativessolutions-4:
代替案/ソリューション ? ?? ?
あなたのストレージにフラグを立ててリエントラントを禁止する。ユーザーにあなたの契約を再入力させる正当な理由がない限り、これはおそらく最良の選択肢である。
- 信頼できる契約またはデフォルトアカウントへの振込のみ。既定のアカウントはコードを実行できないため、常にコードに転送するのが安全です。契約を信頼する前に、その動作を変更できないこと、およびその信頼性が極めて高いことを確認してください。
消費可能な契約に他の人のための資金を保管しない[編集]
Tezosでは、契約書に費用がかかると表示されます。費用のかかる契約の管理者は、契約内に保管された資金を使用して送金を行うことができます。これにより、コードに表示されている契約の動作についての保証を無効にすることができます。
.. _possible-issues-5:
潜在的な問題 サブ>
- 契約の資金を取り除くことができます。
- 契約は義務を果たさない可能性があります
..alternativessolutions-5:
代替案/ソリューション ? ?? ?
あなたが支配していない消費可能な契約に資金を保管しないでください。