一直在研究 Succinct Attestation 實際上是如何處理一次迭代的，結果有一段關於失敗路徑的內容總在我腦海裏揮之不去。
最直觀的故事是：一個委員會驗證一個區塊、批准它，就完了。但 Dusk 的協議並不只是記錄“有效”與否——它記錄的是 Attestation（證明），而且失敗的 Attestation（一個法定人數一致認爲某個區塊*不是*有效）是一個一等結果，而不是事後才處理的附加項。
我之前沒想到的是：在結構上，拒絕比接受更容易。要批准一個有效區塊，委員會必須真正去驗證狀態轉移、簽名，以及整個候選區塊。要形成失敗的 Attestation，委員會成員只需要獲得壓倒性多數的一致同意，認爲*某些東西*出了問題——例如數據格式錯誤、提議者有問題、超時等。這個檢查要淺得多。
因此在機制上，一個壞區塊可能比一個好區塊更快達到它的法定人數門檻——並不是因爲網絡偏愛無效區塊，而是因爲拒絕不需要重建正確性，只需要識別“它不存在”。這不是缺陷。事實上，這正是爲什麼迭代會存在：快速失敗，把該時隙交給下一個提供者，並保持區塊時間的可預測性。
不過，我仍在思考當委員會規模會隨着質押分佈而變化時，這種非對稱性意味着什麼。更快的拒絕會不會變成一種攻擊面，還是說這只是按設計體現出來的韌性？
@Dusk_Foundation #dusk $DUSK
最直觀的故事是：一個委員會驗證一個區塊、批准它，就完了。但 Dusk 的協議並不只是記錄“有效”與否——它記錄的是 Attestation（證明），而且失敗的 Attestation（一個法定人數一致認爲某個區塊*不是*有效）是一個一等結果，而不是事後才處理的附加項。
我之前沒想到的是：在結構上，拒絕比接受更容易。要批准一個有效區塊，委員會必須真正去驗證狀態轉移、簽名，以及整個候選區塊。要形成失敗的 Attestation，委員會成員只需要獲得壓倒性多數的一致同意，認爲*某些東西*出了問題——例如數據格式錯誤、提議者有問題、超時等。這個檢查要淺得多。
因此在機制上，一個壞區塊可能比一個好區塊更快達到它的法定人數門檻——並不是因爲網絡偏愛無效區塊，而是因爲拒絕不需要重建正確性，只需要識別“它不存在”。這不是缺陷。事實上，這正是爲什麼迭代會存在：快速失敗，把該時隙交給下一個提供者，並保持區塊時間的可預測性。
不過，我仍在思考當委員會規模會隨着質押分佈而變化時，這種非對稱性意味着什麼。更快的拒絕會不會變成一種攻擊面，還是說這只是按設計體現出來的韌性？
@Dusk_Foundation #dusk $DUSK