花了一些時間思考，讓鏈下代碼影響鏈上授權意味着什麼。
Newton 的 PolicyData oracle 會被編譯成 WASM 組件。在評估過程中，操作符執行該組件，傳入結構化輸入，並將返回的 JSON 作爲運行時數據提供給 Rego 策略，位於 "data.wasm" 下。
起初，我把注意力放在 oracle 能夠獲取什麼上。
更有意思的部分在於：它不被允許達到什麼。
Newton 操作符通過受沙箱的 Wasmtime 來執行 oracle 組件。對私有網絡範圍、迴環地址和鏈路本地地址的請求都會被阻止。因此，oracle 調用的任何 HTTP 端點都必須通過公開 URL 才能訪問。oracle 還可以附帶一個 JSON 模式來描述其期望的參數，從而在提交之前就能捕獲格式錯誤的輸入。
這個邊界是有意義的。
政策 oracle 仍然是可執行程式碼。若讓它探測內部服務，或讓它依賴鬆散形狀的輸入，就會讓授權變成更廣泛的攻擊面。沙箱會縮小程式碼能觸及的範圍，而規格則會縮小呼叫端被期望要求它處理的內容。
但有些東西一直讓人覺得不對勁。
相同的隔離機制讓執行更安全，也可能讓某些整合變得更困難。有些風險系統、合規資料庫或內部核准服務會刻意不透過公開端點提供。將它們連到 Newton 可能需要一個對外可見的閘道、重新設計的存取層，或其他方法來讓相關資料可用。
所以安全邊界並沒有消除信任。
它把問題移到別處。
可以限制 oracle 程式碼，並將其輸入與已宣告的規格進行比對。oracle 可以在 HTTP 請求失敗時，將結構化的錯誤資料作為回應；但 Rego 政策必須在有效資料缺失或存在錯誤時，明確拒絕授權。
完整的 WASM 執行失敗和其他情況不同。Newton 將這種狀況記錄為「DataProviderError」，這表示評估可能會失敗，而不是單純產生一般的拒絕授權結果。
應用程式仍必須決定沙箱之外有哪些公用服務，以及如何保護該服務。
這就是我一直回來想的那個分別。
隔離保護操作員環境不受 oracle 影響。它不會自動保護政策免於不可靠的外部資料，或是私人系統與公開存取之間設計不良的橋接。
這個設計的強度是真實的，因為不會把任意程式碼給予任意的可觸及範圍。
我尚未完全確定的是：這個邊界是否會促進更乾淨的整合，或是把敏感基礎設施推到那些本身會變得重要依賴的公開閘道之後。
Newton 的 oracle 沙箱能否降低針對離線（offchain）政策資料的風險，還是會把其中一部分風險移到必須圍繞它建立的公開介面應用程式上？？
#Newt @NewtonProtocol $NEWT #NEWT $H $AIGENSYN
