在我看來，規範化（canonicalization）是牛頓（Newton）把一個含糊的意圖（Intent）處理成足夠精確的輸入步驟，使得策略（Policy）能夠始終如一地進行評估。
一個原始意圖可能以多種形式到達。對於同一筆交換請求（swap request），一位用戶可能輸入 1 ETH，另一位用戶可能使用 10¹⁸ wei，而還有人可能用資產的代幣符號來指代它，而不是使用其合約地址。用戶可能提供截止時間，也可能省略，因爲他默認系統會自行推斷。
對人類而言，這些表達方式可能看起來是等價的。
但對策略引擎（Policy engine）來說，它們並不是同一份輸入。
在評估之前，牛頓需要把意圖解析爲明確的組成部分：誰請求了該操作、請求的是哪種操作、涉及哪些資產與目標，以及執行受哪些約束所管轄。
只有在那之後，纔可以開始進行標準化（normalization）。
資產標識符、數量、鏈（chain）、接收方（recipient）、截止時間（deadline）、滑點（slippage）以及其他約束，都需要統一的引用、單位、類型和格式，以確保字段順序的變化不會改變意圖的含義。
默認值也需要遵循共同的規則。當必填字段缺失，或某個參數允許多種解釋時，系統不應把選擇權留給每個操作員（operator）自行猜測。應在策略運行之前，將該意圖視爲無效或未充分指定。
一旦字段被驗證並規範化，牛頓就可以構建一個規範表示（canonical representation）：一個單一的語義對象，用來表示原始意圖。隨後，它可以在相同規則下進行序列化，確保每個操作員都接收到同一結構、同一數值與同一含義。
這部分是我認爲至關重要的。
策略不應評估用戶輸入的文字。它應該評估規範化後的意圖——在移除了格式、單位與表達差異之後。
如果這一步失敗，即使是確定性的策略也無法拯救系統。
只有當每個操作員在策略評估之前都接收到同一個規範意圖時，牛頓才能維持授權（authorization）的⼀致性。
@NewtonProtocol $NEWT #Newt $LAB $BTW
一個原始意圖可能以多種形式到達。對於同一筆交換請求（swap request），一位用戶可能輸入 1 ETH，另一位用戶可能使用 10¹⁸ wei，而還有人可能用資產的代幣符號來指代它，而不是使用其合約地址。用戶可能提供截止時間，也可能省略，因爲他默認系統會自行推斷。
對人類而言，這些表達方式可能看起來是等價的。
但對策略引擎（Policy engine）來說，它們並不是同一份輸入。
在評估之前，牛頓需要把意圖解析爲明確的組成部分：誰請求了該操作、請求的是哪種操作、涉及哪些資產與目標，以及執行受哪些約束所管轄。
只有在那之後，纔可以開始進行標準化（normalization）。
資產標識符、數量、鏈（chain）、接收方（recipient）、截止時間（deadline）、滑點（slippage）以及其他約束，都需要統一的引用、單位、類型和格式，以確保字段順序的變化不會改變意圖的含義。
默認值也需要遵循共同的規則。當必填字段缺失，或某個參數允許多種解釋時，系統不應把選擇權留給每個操作員（operator）自行猜測。應在策略運行之前，將該意圖視爲無效或未充分指定。
一旦字段被驗證並規範化，牛頓就可以構建一個規範表示（canonical representation）：一個單一的語義對象，用來表示原始意圖。隨後，它可以在相同規則下進行序列化，確保每個操作員都接收到同一結構、同一數值與同一含義。
這部分是我認爲至關重要的。
策略不應評估用戶輸入的文字。它應該評估規範化後的意圖——在移除了格式、單位與表達差異之後。
如果這一步失敗，即使是確定性的策略也無法拯救系統。
只有當每個操作員在策略評估之前都接收到同一個規範意圖時，牛頓才能維持授權（authorization）的⼀致性。
@NewtonProtocol $NEWT #Newt $LAB $BTW