今回の記事では、『Timelockが重要ではない理由』について解説していきたいと思います。
主にDeFiの、イールドファーミングにおける話になります。
今までは、Rugpull関連の動画などでも『Timelockがあるかどうか確認してください』という話をお伝えしてきたと思います。ただ、この数週間で結構状況も変わり色々考えた結果Timelockはさほど重要ではないなという結論に至りました。その理由を今回は紹介したいなと思うので、是非最後まで読んで頂ければと思います。
Timelockとは
Timelockのメインは引き抜き用のコード対策です。人のプールに入れてあるトークンを勝手に引き出すことができるので危険なコードと言われています。
そのため、悪意のあるプロジェクトがこういった機能を使うとどんどん資金を引き抜く事が可能でした。なので、TImelockをしている間はそうゆう機能が使えなくなるので安全だと思われています。
この記事の前提として、Timelockがあるから悪いというわけではありません。機能としては良い機能ですし、防御するという点においては、役に立つ場面もあるかと思います。
ただ、『Timelockがあるから安全』『Timelockがあるから大丈夫』という考え方は無くしてほしいなと思いこの記事を書いています。
まずはTimelock主な仕組みを2つ紹介します。
①オーナーのみの機能の実行を遅らせる
（例）MasterChef
MasterChefに一番利用されていることが多いです。
MasterChefのオーナーにTimelockを設定することで、オーナーの機能を使いたい場合はTimelock経由でMasterChefに機能を飛ばす必要があります。
Timelockにこの関数を実行したいという物を飛ばすと、６時間や２４時間後ぐらいにMasterChefで実行されます。具体的に何時間後に実行されるかは、Timelock側で決められます。この【何時間後に実行する】というこの機能がTimelockです。
②結果的にMasterChefなどの変更が即座に行われたりしない
Timelockを設定した事で結果的に、MasterChefの変更がすぐに行われる事はないです。逆にTimelockがない場合だと、開発者が実行したらすぐに変更されます。
なので、その時間何も変更されないということはラグプル起こらないよねと思われていました。ここが結果的に、勘違いの原因になってしまっていました。
重要ではないと思う理由３つ
私自身もTimelockがあることで安全だと思い込んでいました。ただ、最近のラグり方やRugpullのケースを見ているとTimelockが関係ないと思い始めました。
逆に、Timelockがあることで人が集まってしまいより被害が拡大しやすです。自分自身が被害を受けない為にも、Timelockに対する考え方は直したいと思った理由が、下記３つです。
①オーナー機能以外は利用できる
Timelockをしている間、オーナー機能以外は利用できます。
そして、現在のRugpullの主要なやり方はオーナー機能以外を使って行うやり方になっています。
例えば最近、stablemagnetでRugpullがありました。Swapと言われる普通のユーザーが使える機能を使ってラグっています。
ユーザーが使える機能＝オーナーもすぐに発行ができるので、Timelockのあるなしに関係なく実行できます。
つまり、ユーザーも触れる範囲に何かセキュリティのホールを作っておくとすぐにラグることが可能です。これが、今の主要なやり方になっています。このようなRugpullが増え結果的にオーナー機能を使わなくても、ラグれてしまうという状況になっています。
結論：Timelockがあっても無くても、普通の機能は使えてしまうので意味がない！
②防御も遅らせてしまう
Timelockは攻撃を受けたときの防御も遅らせてしまいます。この場合、悪意の無いプロジェクトにとっては邪魔でしかないです。
Timelockは運営がラグるパターンだけでなく、第三者からの攻撃を受ける場合もあります。
例えば、パンケーキバニー／IRONFINANCEのように、運営側に悪意が無くても攻撃を受けてしまった場合。防御の際もTimelockを経由する必要があるので、その度に２４時間待つことになります。これだと明らかに手遅れになり、防御を遅らせてしまう事に繋がります。
結論：Timelockは防御の邪魔になる！
③逐一確認する労力をかけるユーザーや機関が無い
Timelockはdelay（実行されるまでの時間）が設定されていてQueueという形で実行される予定のものが蓄積されていきますが逐一確認する労力をかけるユーザーや機関が無いです。
Queueで蓄積されていくことで、ユーザーはそれを見てRugpullと判断し抜けていくと思いますが。プロジェクトやプロトコルがありすぎて、全て確認することは出来ていないと思います。
確認する機関もないので、現実的に全てを把握すること自体が不可能だと思っています。なので、Queueで保存されていてもいなくても気づかなかったら意味がないと思います。仮にQueueに入っていても、気づかないうちに実行されラグられたら終わりです。
結論：気づかなかったらTimelockを設定してあっても意味がない！
まとめ
大きく上記３つの理由で、Timelockがそこまで重要ではないと考えてます。
私個人の意見として、Timelockがあるかないかではなく。そもそも、Timelockがないと安心できないようなプロジェクトには大金を突っ込まないというのが結論です。
Timelockを信用しすぎないようにし、一つの材料として見れるようになるといいんじゃないかなと思い解説しました。
RugDoc
RugDocが出しているWikiでTimelockについてよく知って欲しいという内容があったので紹介していきたいと思います。
紹介URL▶RugDocWiki
背景情報
背景情報から見ていきます。
①ラグらないか確認したいという意味。
Masterchefのプールにユーザーはデポジットしていると思いますが、Masterchefのオーナーが外に資金を流したら結果的に全部資金が流されてしまうので金庫のように考えてください。
②ラグってしまうと100%とられてしまうという意味。
みんなの資金をまとめて集めている金庫があったとして、その金庫の鍵を持っている人はいつでもアクセスできるし全部持っていけます。しかも、今回は電子情報なので物量的に持てないとい事もないし、一瞬で持っていけてしまう。
結論：安全なプロジェクト・信頼できるプロジェクトに資金は入れましょう！
タイムロックとは正確には何ですか？なぜ気にする必要がありますか？
タイムロックとは、【Timelock】というクッションを挟む事で、オーナーの実行を遅らせる事ができる。
Timelockの事を、boxとここでは表記してあります。
①金庫の鍵を開けようと思うと、すぐに開けることができない。
このボックスは設定可能なタイマーが設定されているという点で特別である。所有者がキー入れて閉じると、ボックスが自動的にロックされる。所有者が鍵を中に入れたい場合はタイマーを開始する必要があり、タイマーが切れるとロックが解除される。これによって悪意のある所有者の能力が低下される。
②内部のコードを書き換える事ではなくて、いつ呼び出すかだけが変更される。
※金庫の話から、スマートコントラクトの話に切り替わっています。
Queueに入れられるトランザクションは、通常変数を更新したりMasterchefスマートコントラクトに存在する関数を呼び出したりすることを目的にしている。
タイムロックについての真実
①オーナーが資金を盗む可能性がある場合のみに便利。
鍵のコピーが無ければ、銀行の金庫室の鍵を使っていつでも金庫室にアクセスすることができる。そのため、所有者の能力が重要ではない。
②ラグのリスクが低い場合は、そもそもTimelockは関係ない。
Timelockは、オーナーから身を守るのを助けるだけです。そのため、オーナーではない機能を使われてしまうと意味がない。
③オーナー機能ではない所にセキュリティホールを作ると実行できてしまう。
所有者は、マスターボールトキーをタイムロックに『デポジット』する前にそのコピーを作成でき全てを盗むことが可能。これは、スマートコントラクトが開発者ロールの機能を隠してアクションを実行できるようにする場合のようになります。
④所有者はTimelockのタイマーを短く設定することも可能。
タイマーが６時間しかない場合、所有者は夜にタイマーを開始しユーザーが目を覚ます前にユーザーの資金で逃げることが可能。
タイムロックが有害な場合
オーナーが悪意がない場合Timelockをかけるだけ邪魔になる。
Timelockの間は誰も中に入ることができない為、その間に事件が大きくなりやっと中に入れた時には資金が全てなくなってしまう。
結果的に守る時にも邪魔になる！！
まとめ
以上がRugDocに記載してあった内容になります。
DeFiを行う上で、基本的に自分で情報を集め実践されている方がほとんどだと思います。是非このRugDocも参考にしていただいて、一つの学びとして見ていただければと思います。
今回はTimelockが重要ではないという内容をお伝えしましたが、もちろんTimelockがあってはいけないというわけではないです。Timelockも目的があって一つの機能を守ることができています。
ただ、『Timelock＝安全・安心』この考えが少しでも変われば自分の資金を守ることに繋がるのではないかなと思います。
