tBTC：分散型の償還可能なBTCで裏付けられたERC-20トークン
失敗の処理
中絶/活気
システムでは、資金調達や償還などの重要なアクションが、リクエスト後の一定時間内に発生する必要があります。そうしないと、「中止」として扱われます。詐欺が禁止された行動の証拠を示している場合、中絶は通常、一部の参加者による活力の失敗を表します。そのため、中絶は依然として罰せられ、清算につながる可能性がありますが、詐欺ほど厳しく罰せられることはありません。たとえば、署名者が適時に償還署名を作成しなかった場合、彼らの債券は供給ペグを保護するために清算されますが、清算開始者が報われると、残りはすべて彼らに返還されます。
詐欺
システムは、1つのタイプの不正防止であるECDSA不正防止を認識します。この場合、署名グループは、明示的に要求されていないメッセージに署名を生成します。詐欺が検出されると、システムは署名者の絆を奪い、清算プロセスを開始することで署名者にペナルティーを科します。
ECDSA不正防止
署名者は、ECDSAキーペアをまとめて制御します。協力することで、公開鍵の下で署名を作成できます。署名者は、特定の署名を作成する責任があります（たとえば、償還プロセス中の償還トランザクションで）。署名者の公開鍵の下にあるが、システムによって特に要求されていない有効な署名は、詐欺と見なされます。
ECDSA詐欺証拠は、署名者の公開鍵の下の署名、署名されたメッセージダイジェスト、およびそのダイジェストのプリイメージです。そこから、定期的なECDSA検証を実行します。プリイメージがダイジェストと一致し、ダイジェストの署名が有効であるが、ダイジェストがシステムによって明示的に要求されていない場合、署名者セットの信頼性が失われていることを確認できます。ここで注目に値するのは、プリイメージとダイジェストの関係の検証をスキップできない場合があるということです。任意の公開鍵が与えられると、その公開鍵の下に署名を作成し、それに一致するダイジェストを選択することができます。つまり、誰でも未知のメッセージに対して明らかに有効な署名を作成できます。攻撃者はこの関係を偽造するためにハッシュ関数を反転する必要があるため、プレイメージの存在を直接検証する（署名されたダイジェストとの関係を確認する）だけで、この攻撃を防ぐことができます。
概念的には、システムは署名者が作成した署名を検証できます。ただし、ホストチェーンの機能には実際的な制限があります。たとえば、イーサリアムでは、特定のダイジェスト関数しか使用できないため、サポートされていないハッシュ関数によって生成されたダイジェストの署名を検証できません。実際の例として、これはblake256を使用するDecred署名の検証を排除します。イーサリアムがホストするシステムの署名者は、罰せられることなく、Decredトランザクションで署名を作成できます。
すべてのホストチェーンは引数のサイズにコストを課すため、検証のコストはプリイメージの長さに比例します。これは、非常に長いプレイメージで署名を検証することが経済的に実現可能でない可能性があること、または検証しようとするとリソース使用の制限（Ethereumのブロックガス制限など）を超える可能性があることを意味します。幸い、ビットコインの署名ハッシュアルゴリズムはdouble-sha256を使用します。これにより、署名のプリイメージが最初のsha256の結果になります。これは、署名されたダイジェストへのプリイメージが常に32バイトであることを意味します。つまり、検証コストがトランザクションサイズに比例することはなく、非常に大きなトランザクションでもECDSA不正検証を回避することはできません。
償還
概要
預金は実際のビットコインの未使用トランザクション出力（「UTXO」）を表し、そこで保持されているBTCと引き換えることができます。 tBTC償還システムは、公的に検証可能なプロセスを介してそれらのBTCへのアクセスを提供することを目的としています。
預金が良好な状態に保たれている限り、代替不可能なtBTC預金トークンの所有者は、償還を要求し、NFTを放棄し、預金に関連する未払いの署名者手数料を支払うことができます。
この時点で、償還プロセスはキャンセルされない場合があります。
償還が要求されると、署名者は、基になるBTCを要求されたアドレスに送信する有効なビットコイン署名を生成する必要があります。署名が公開された後、すべてのアクターは、その署名を使用して*償還トランザクション*を構築し、ビットコインブロックチェーンに送信できます。
預金条件と償還
デポジット条件のセクションに記載されているように、デポジットには固定期間があります。その期間が満了すると、預金は預金所有者からロック解除され、任意のアカウント（特に預金所有者アカウントを含む）で引き換えることができます。この時点で、償還には預金のロットサイズとまったく同じ費用がかかり、署名者の手数料はかかりません。 TBTCの採掘中に預金に署名者料金がエスクローされた場合、署名者料金はエスクローから支払われ、預金所有者にはTBTCでフルロットサイズが送られます。預金にエスクロー手数料がない場合、所有者には、償還に使用されたTBTCが送られ、署名者に分配される署名者手数料が差し引かれます。
注意
預金所有者の場合、期限内に、エスクロー料金がある場合は償還は無料であり、ない場合は署名者料金がかかります。これは、預託手数料がある場合でも預金所有者が署名者手数料を支払わなければならない早期償還とは微妙に異なります。追加の差額は、料金リベートトークンの所有者に送信されます。この所有者は、期限前の償還中に署名者の料金をリベートしますが、期限内の償還中にはリベートしません。
償還リクエスト
引き換えリクエストは、いくつかのケースで送信できます。
-預金が良好な状態にあり（まだ償還されておらず、詐欺の罪で告発されておらず、署名者の清算に入っていない）、期限が過ぎており、要求者が対応するtBTC預金トークンを保持している場合。
-デポジットが良好な状態であり、期限が過ぎている場合は、リクエスターが対応するtBTC DeopsitTokenを保持しているかどうかに関係なく。
-預金が表敬訪問に入った場合、要求者が対応するtBTC預金トークンを保持しているかどうかに関係なく、危険なほど担保が不足する前に預金を閉じることができるように設計された担保不足の状態。
リクエスターは、償還をリクエストするために、ホストチェーン上のスマートコントラクトに対して*償還リクエスト*トランザクションを行います。 *償還リクエスト*には次のものが含まれます。
1.ビットコイン取引手数料の金額。
◦> = 2000 satoshi（〜20 satoshi / vbyte）である必要があります
2. BTC配信用の標準出力スクリプト（p2pkh、p2sh、p2wpkh、またはp2wshのいずれか）。接頭辞はスクリプトの長さです。セキュリティとプライバシーのために、これは新しいキーペアによって制御されるべきです（SHOULD）。
3.TBTCでのデポジットの返済額。
*償還リクエスト*を受信すると、スマートコントラクトは返済額（期日があれば署名者料金を含む）をエスクローし、リクエストの受信を記録し、署名が必要であることを署名者に通知します。
償還要求が通知されると、署名者はホストチェーンでの確認を待つ必要があります。彼らが確認を待たない場合、償還要求は再編成を介してチェーンから削除される可能性があります。その場合、彼らが作成した署名は、BTCの償還と署名者の不正証明の提出の両方に使用できます。この方法で作成された不正防止は、償還要求の記録がなくなったため、ホストチェーンのスマートコントラクトには有効であるように見えます。
返済額
概念的には、返済額は、預金ロットサイズに1 TBTC（50ベーシスポイント）あたり0.005TBTCの署名者料金を加えたものです。これにより、署名者は償還の完了時に支払われ、所有者は償還された預金の補償を受けることができ（所有者以外の当事者による償還）、料金リベートトークンの所有者は料金のリベースを受け取ることができます（早期償還） ）。
すべての計算が終わった後、返済額は、償還当事者、TDT保有者、FRT保有者、および預金の期間状態によって異なる可能性があります。預金支払いフロー表には、A、B、Cの3つの可能な当事者を想定した、可能なさまざまな組み合わせと、償還者が支払うべき対応する返済額が一覧表示されます。また、償還証明に関連する支払いも一覧表示されます。
償還取引フォーマット
償還トランザクションは、tBTCホストチェーンで実行されているスマートコントラクトに組み込まれている完全に正規の形式です。これにより、tBTCシステムに対する多くの複雑な攻撃が防止され、契約ロジックが簡素化されます。リクエスターは、トランザクションの2つの側面（料金と宛先）のみを指定できます。他のすべての預金固有の情報（アウトポイントやUTXO値など）は、事前に預金契約に知られています。
*償還取引*には、1つの入力（預金UTXO）と1つの出力（償還出力）があります。変更出力や追加入力は必要ないため、ありません。基になるBTCをリクエスターの唯一の管理下に転送するだけです。タイムロックとシーケンス番号は0に設定され、バージョンは1に設定されています。形式とそのため息の構成の完全なドキュメントは、付録にあります。
形式は単純で標準的であるため、どのオブザーバーも公開されている情報を使用して作成できます。署名が公開されると、トランザクションに証人を追加してブロードキャストするのは簡単です。したがって、署名者はトランザクションをできるだけ早くブロードキャストする強いインセンティブを持っていますが、署名者がそうしない場合は誰でもそうすることができます。
償還証明
*償還証明*は、*償還取引*がビットコインブロックチェーンによって確認されたことを示すSPV証明です。引き換えのリクエストが確認されると、デポジットスマートコントラクトは6時間以内に*引き換え証明*を期待します。 *償還証明*を検証するために、スマートコントラクトは通常のSPV証明検証を実行し、さらに受信者が要求者の指定された出力スクリプトと一致し、値が「UTXO値-最高許容料金」以上であることを確認します（詳細については、ビットコイン手数料の調整）。
償還証明が確認されると、署名料が支払われ、FRT保有者はエスクローされた資金を受け取り（預金が早期に償還された場合）、TDT保有者は残りの返済額を受け取ります。返済額と同様に、償還が成功した場合に各当事者が受け取る金額は、TDT保有者、FRT保有者、償還者、および預金の状態によって異なります。預金支払いフロー表には、A、B、Cの3つの可能な当事者を想定して、可能なさまざまな組み合わせと、償還者が支払うべき対応する返済額が一覧表示されます。
署名の検証
ホストチェーンで償還リクエストが十分に確認された後、署名者はリクエストに応じて*償還トランザクション*署名ハッシュで署名を作成する必要があります。罰則の対象となる前に、署名または*償還証明*のいずれかを作成するための3時間の猶予があります。有効な署名を提出した場合でも、*償還証明*が必要ですが、期限は合計6時間に延長されます。
前に説明したように、預金を管理するホストチェーンのスマートコントラクトには、*償還トランザクション*の署名ハッシュを計算するために必要なすべての情報が含まれています。これには、署名者のしきい値公開鍵が含まれます。スマートコントラクトは、公開鍵、署名ハッシュ、および償還要求を使用して、署名の暗号化の有効性と、償還プロセスの一部としてそのダイジェストの署名が要求されたことの両方を知ることができます。
ビットコインの手数料調整を可能にする
ビットコインの料金はネットワークの混雑やその他の非常に予測不可能な要因によって決定されるため、要求者は適切な料金を選択しない場合があります。償還証明が提出されない場合、または明示的な承認なしに署名した場合、署名者は罰せられます。これにより、署名者にとって勝ち目がないシナリオが作成される可能性があります。このシナリオでは、現在の料金環境では要求者の取引を確認できず、正直な行動にもかかわらず最終的に罰せられます。残念ながら、リクエスターがオンラインを維持したり、料金レートを正直に更新したりすることを信頼することはできません。エルゴ、システムには、要求者の明示的な同意なしに料金レートを公正に調整するための何らかのメカニズムが必要です。
最も単純なスキームは、タイムアウト後に署名者が要求者の同意なしに料金を引き上げることを許可することです。そのため、署名者は4時間ごとに直線的に料金を引き上げることができます。つまり、手数料が「f」の場合、4時間後に署名者は預金契約に「2f」への手数料の引き上げを通知でき、8時間後も取引が未確認のままである場合、署名者は契約に手数料を通知できます。 `3f`に増やします。これにより、現在のネットワークの混雑を考慮して、ビットコインブロックチェーンで最小料金に近い償還トランザクションが最終的に確認されます。署名者が繰り返し料金の値上げを要求するのを防ぐために、署名者は実際に各料金レベルで署名を提供する必要があります。これにより、値上げが要求される前に、各料金が実際に試行されます。
ガバナンス
哲学
ガバナンスの哲学は単純です。可能な限り少ないシステムパラメータを管理します。ガバナンスに関するこの限定された見方は、ガバナンスされた契約のアップグレードではなく、ソーシャルアップグレード（システムの新しいインスタンスの展開）に依存することを意味します。
ソーシャルアップグレードは、ハードフォークに似ています。新しいトークン契約やその他の新しい契約は市場全体で調整および合意する必要があるため、圧倒的な経済的コンセンサスが必要です。ソーシャルアップグレードの基準は、他の一般的なガバナンスパラダイムよりもはるかに高く、システムのインスタンスが古くなるにつれてさらに困難になります。
システム設計に含まれる限定的なガバナンスは、いくつかの原則に従います。
-ガバナンスは、可能な限り、新しい預金にのみ影響を与える必要があります。各預金は、ガバナンスの選択に関係なく、長期的には予測どおりに動作する必要があります。
-すべてのガバナンスは、可能であれば時間遅延を遵守し、ユーザーがシステムの変更に対応する時間を与える必要があります。
-ガバナンスの役割は、信頼できる中立的な第三者または最終的な地方分権化に割り当てられる必要があります。
ガバナンス機能
すべてのガバナンス機能と遅延を以下に列挙します。それぞれは、契約所有者だけが呼び出すことができなければなりません。時間遅延のある関数の場合、指定された遅延後に変更を確定できる「begin <Function>」と同等の「finalize <Function>」があります（例：「beginLotSizesUpdate」/「finalizeLotSizesUpdate」）。
新たに発見された脆弱性の場合の不変のコードとユーザーの安全性は、しばしば相反するものと見なされます。代わりに、多くのスマートコントラクトシステムは信頼できる管理者キーに大きく依存しており、任意のコントラクトのアップグレードが可能です。もちろん、そのような機能が存在する場合、なぜブロックチェーンを使用するのですか？
契約のアップグレードの代わりに、tBTCv1には新しい預金を10日間一時停止する機能が含まれています。この機能は一度使用でき、既存の預金やその他のシステム機能には影響しません。 10日間の期限が切れると、新しい預金が再び有効になります。
この機能により、開発チームはゼロデイエクスプロイトの場合に新しい預金を一時停止し、貴重な時間を購入して、資金に対するリスクをユーザーに警告できます。インテントは悲惨な状況で使用することを目的としていますが、メカニズムは構造化されているため、開発チームはそれを汎用のキルスイッチとして使用できません。
365日を過ぎると、デポジットを一時停止できなくなり、 `emergencyPauseNewDeposits（）`の呼び出しを元に戻す必要があります。
`beginLotSizesUpdate（uint64 [] _lotSizes）`
契約の所有者は、2日遅れて、新しいデポジットが有効になっているロットサイズを更新できます。
このコールが不注意によるキルスイッチとして機能しないようにするには、常に1BTCロットサイズを有効にする必要があります。 1 BTCロットサイズを含まない更新は、元に戻さなければなりません。
`beginSignerFeeDivisorUpdate（uint16 divisor）`
残念ながら、tBTC v1の設計では、市場で発見可能な署名者料金は考慮されていません。代わりに、署名者料金を設定する機能はガバナンスに任されています。
契約の所有者は、2日遅れて署名者料金の除数を更新し、新しい預金に影響を与える可能性があります。非常に小さいまたは非常に大きい署名者料金の更新がキルスイッチとして機能するのを防ぐために、料金は0.03％〜10.0％に制限されています。
その範囲外の更新はすべて元に戻さなければなりません。
`beginCollateralizationThresholdsUpdate（uint16 initial、…）`
契約の所有者は、2日遅れて、新しい預金の担保のしきい値を更新できます。
更新は新しい預金に直接影響を与えるだけですが、契約の所有者が攻撃者と共謀した場合、更新はペグに害を及ぼす可能性があります。そのため、100％未満または300％を超える初期しきい値は元に戻さなければなりません。
`beginEthBtcPriceFeedAddition（address ethBtcPriceFeed）`
契約の所有者は、90日遅れて、すべてのデポジットに対して新しいバックアップETHBTC価格フィードを追加できます。この遅延は、他のガバナンス制御よりも大幅に長いことに注意してください。
価格フィードはリストで追跡する必要があり、そのリストの価格フィードは、以前に追加されたすべての価格フィードが*非アクティブ*である場合にのみ*使用*する必要があります。価格フィードは、フィードがアクティブかどうかを示すブール値とともに価格フィードの値を返す `peek（）`関数を提供します。その戻り値の2番目の値が「false」の場合、フィードは非アクティブと見なされ、リスト内の次のフィードを使用する必要があります。
この更新により、プライマリMedianizerフィードを意図的に廃止するための簡単な計画が可能になります。長いリードタイムにより、新しい価格を懸念している可能性のある既存の預金者は、オープン預金を閉じて資金を回収するのに十分な時間を確保できます。
この更新は、プライマリフィードの予期しない非アクティブ化に対処するためにも使用できますが、その場合、システムの回復には90日かかります。
