DAOのハックの問題がありました。
今ではみんなわかっていて避けています。
これはDAOと一緒の原因、2年経っても同じハックが起きる
QuantstampはSmartcontratのLifecycleを守る事業
Auditなど
開発をまだまだ進めている。
スマートコントラクトセキュリティは今までデプロイ前でした。あとにセキュリティを保つにはどうしたら良いのでしょうか。
テスト監査安全なデプロイなどが考えられますが、本番に出てからどのように強化するかは考えられていませんでした。
コントラクトモニタリングという観点で、あまりに疑わしいトランザクションパターンが出てきたらモニタリングツールが検出することができる。
難しい面もある。ハッキングされたらどうなるか
一部のコントラクトはPauseできて、ハッキングされたら一時停止してどうするか考えることができるものがある。
ハッキングされたあとは原因を探して二度と起こらないようにして先に進めることになりますが、何千ドル単位から何万ドルという単位まで現行のやり方田はあまり現実劇ではありません。
StakingProtocol
左側はコントラクトを使いたい人、開発して使って欲しい人達。
右側がセキュリティエキスパート。監査人や個人開発者など。スキルから報酬を得る
我々のプロトコルはこの2者を結びつける
SecurityExpertはコントラクトが安全であることにStakeする。
第三者、トークンを持っていて投資したい人が入っても構わない。
安全にコントラクトが運用されたらいいが
ハックされたらステークされたものをユーザーがもらえる
脆弱性の定義
悪いふるまいが何なのかはステークホルダーが決める。どのようなカバレッジが必要化は彼らが決める。
わざとバックドアを用意する場合がある。バックドアをハッキングして保険料を得ようという悪さがありうる。
そのためにセキュリティの専門家がチェックしてバックドアがないことを確認する必要がある。
安全だという自身があることでこれに対してトークンをステークするか自分で選べる
このためには
ハックされたかどうかを決めなくてはいけない。
ポリシーコントラクト:残高が0で無い限り使いたいとすると
これが0になると攻撃されたということになる。攻撃されたかされてないかをこのように判定する。
ステークホルダーがポリシーのコントラクトアドレスをSubmitする。
いろいろな条件があり、支払い頻度、ポリシーの長さがどれくらい(有効な期間)など。
SecurityExpertは対象コントラクトとポリシーコントラクトを両方検査する。
適切な状態を理解した上でトークンをステークするか決める。
スケーラブルなVerificationができる。コントラクトのセキュリティとして使える。これを個人が利用できる。決定論的なコントラクトがあることで違反があるかを検査できる。安全性がます。Policyコントラクトがあればスコープを減らすこともできる。何が脆弱性となるのかを決定できる。
現在セキュリティエコシステムには足りない部分があると思う。モニタリングも重要。このレイヤを追加することでセキュリティがデプロイメントのあとにも適用できるということになると幅広くスマートコントラクトが適用されていくと思います。