#bedrock $BR 最近、ちょっと恥ずかしいことがありました。あるDeFiプロトコルが契約をアップグレードするというアナウンスを出して、ユーザーに流動性を手動で移行するように求めました。マニュアルに従って操作したところ、権限の承認段階でミスが発生し、ガス代を一度消費した後、移行に失敗しました。再度試みましたが、また失敗。最後にコミュニティで聞いてみたところ、これは個別のケースではなく、契約アップグレードの互換性の問題だとわかりました。半時間以上も手間取ってしまい、その後「プロトコルアップグレード」という言葉に対して警戒心が増しました。$ETH
その後、@Bedrock のドキュメントを見て、契約のアップグレードメカニズムを特に調べました。
Bedrock 2.0のアーキテクチャでは、核心的な契約、例えばuniBTCやbrBTCの発行ロジックは、自由に変更できるものではありません。アップグレード権限はマルチシグの手にあり、そのマルチシグはBedrock自身だけではありません。アップグレードのたびに、複数の独立した当事者の共同署名が必要です。このメカニズムは「プロジェクト側の悪行」のリスクを完全に排除することはできませんが、少なくともハードルを上げました。一人の意見ではなく、群衆の同意が必要です。

さらに気になったのは、Bedrockはアップグレードに関して、多くのパラメータを置き換え可能ではなく、構成可能にしている点です。どういうことかというと、あるプロトコルが収益率パラメータを変更したい場合、全体の契約を交換しなければならず、リスクが高く、操作が複雑です。Bedrockは設計当初から、手数料、インセンティブ配分、プールの重みなどの一般的なパラメータを構成可能な項目として作成し、ガバナンストークンの投票によって調整できるようにしました。これにより、核心的な契約に手を加えることなく柔軟性が保たれ、アップグレードによるリスクエクスポージャーが低減されました。

その歴史的な監査報告書を一通り見ました。Bedrockの核心的な契約は、SlowMistやCertiKなど、複数の監査会社によるクロス監査を受けています。監査は100%のバグのないことを保証するわけではありませんが、複数回の監査は少なくともチームがセキュリティに真剣に取り組んでいることを示しています。$BTC
もう一つの詳細として、Bedrockの契約アップグレードのタイムロックがあります。緊急でないアップグレードは、発動後に一定の時間遅延があり、その間にコミュニティが反応する時間が与えられます。もしアップグレード提案に異議がある場合、コミュニティはこの期間中に問題を発見し、異議を申し立てることができます。このような設計はDeFiの領域では珍しくありませんが、実際に厳格に実行されているプロジェクトはあまり多くありません。