可以通過軟分叉添加新的 OP 程式碼嗎？
我知道 P2SH 交易類型是通過重新利用已經有效的 Tx 消息“軟”添加的，因此舊節點不會在塊中拒絕它們。
是否有類似的方法可以在沒有硬分叉的情況下添加新的腳本 OP 程式碼？換句話說，舊節點在重新用於升級協議後將如何解釋“No Op”命令？
是的。在 P2SH 之前，解決 P2SH 解決的問題的最流行的建議是 OP_EVAL，它就是這樣做的：它將 OP_NOP1 重新定位為 OP_EVAL。
P2SH 腳本如下所示：
[script input...] [serialized script] | OP_HASH160 [script hash] OP_EQUAL等效的 OP_EVAL 腳本在舊節點看來如下所示：
[script input] [serialized script] | OP_DUP OP_HASH160 [script hash] OP_EQUALVERIFY OP_NOP1舊節點僅在散列時檢查序列化腳本是否與給定腳本雜湊匹配。其他的東西會被忽略。
新節點會看到：
[script input] [serialized script] | OP_DUP OP_HASH160 [script hash] OP_EQUALVERIFY OP_EVAL新節點會理解 OP_EVAL，因此他們會檢查序列化腳本是否與給定腳本匹配並執行序列化腳本。OP_EVAL 事務可能被視為對新節點無效而對舊節點有效，但反之則不然。這就是使它成為軟分叉的原因。如果大多數算力都在使用新規則，那麼這不是硬分叉，因為最長的鏈總是會收斂到對新舊節點都有效的狀態。
根據新操作碼的行為，新節點可能需要兩次驗證腳本以確保某些腳本不會導致硬分叉。使用舊腳本規則和新規則驗證腳本一次。
OP_EVAL 提案最終被 P2SH 取代，因為發現 OP_EVAL 意外地允許了圖靈完備的腳本，這是比特幣開發人員不想要的。P2SH 在某種程度上非常簡單（而且有點奇怪），因此很容易避免類似的事故。但是這種添加新操作碼的方法沒有任何技術問題。此外，沒有什麼限制新操作碼的行為。例如，OP_EVAL 可以用另一種圖靈完備的語言解釋其輸入，儘管這可能不是一個好主意有多種原因。