修訂智能合約
如果我創建了一個支付使用者共享數據的智能合約，如果它有錯誤，或者我希望更改為數據共享支付的金額，我該如何更新這個智能合約？據我了解，我基本上必須在新的乙太坊地址創建一個新的智能合約，並以某種方式將我的使用者重新連接到這個新合約。如果屬實，這又會讓人感覺很像中心化系統，智能合約編寫者可以根據需要更改規則（支付率）。顯然我在這裡遺漏了一些東西……可以請解釋一下嗎？謝謝！
如果我創建了一個支付使用者共享數據的智能合約，我該如何更新這個智能合約以防它出現錯誤
儘管無法升級已部署的智能合約的程式碼，但可以設置代理合約架構，允許您使用新部署的合約，就像您的主要邏輯已升級一樣。
代理架構模式是這樣的，所有消息呼叫都通過代理合約，該合約會將它們重定向到最新部署的合約邏輯。要升級，需要部署新版本的合約，並更新代理以引用新的合約地址。更多關於代理模式的資訊在這裡
也許我希望更改為數據共享支付的金額？
您無需更新智能合約即可更改為數據共享支付的金額。實現此功能的更好方法是為費用設置公共狀態變數並公開 ownerOnly 函式以更新它們。
據我了解，我基本上必須在新的乙太坊地址創建一個新的智能合約，並以某種方式將我的使用者重新連接到這個新合約。如果屬實，這又會讓人感覺很像中心化系統，智能合約編寫者可以在他們願意時更改規則（支付率）
這在一定程度上是正確的。但在區塊鏈的情況下，所有事件都是透明的，對合約的任何更改都將在賬本上可見。一些領先的 dapp，如 Kyber、Synthetix 使用代理模式來確保它們能夠在出現錯誤或安全問題時修復程式碼。您還必須考慮智能合約所有者在部署代理合約時擁有多少權力這一事實。
區塊鏈確保你不能改寫過去，所以你不得不放棄修改它的想法。
支付使用者分享他們的數據，我怎麼能更新這個智能合約
聽起來你不想更改契約。相反，您希望您的使用者同意一個流程，讓他們獲得目前的現行匯率，無論是什麼。
將“契約”視為類似於法律協議通常是錯誤的，就好像每個使用者關係都是契約的一個單獨實例。將其視為使用者可以查看並看到您不能隨意更改它的可靠執行過程會更有幫助。
您的流程必須解決一些重要的問題：
- 使用者如何提供數據以及您的契約（或其他使用者）如何接受該提議？
- 價格是如何確定的，買方如何驗證所提供的資訊？
如果您制定了這些業務流程，那麼您可以將它們編入執行流程的智能合約中。
如果未來協議的條款保持在您設置的參數範圍內，則無需修改智能合約。也就是說，您提前預期任何人都需要的靈活性。對於大多數意圖和目的，您將無法選擇更改智能合約，並且參與者的大部分保證都源於此屬性。
必須在新的乙太坊地址創建一個新的智能合約，並以某種方式將我的使用者重新連接到這個新合約
如果契約的實用性隨著時間的推移而惡化，那麼過渡到新事物的過程將是痛苦的，除非您提前製定了過渡過程。
想像一下你以最快的速度射入深空的宇宙飛船。你將永遠無法趕上，所以唯一能在船上的東西就是你放在那裡的東西。你仍然可以和它交談。例如，您可以部署一個新模組並將其集成，但前提是宇宙飛船是為動態更換組件而設計的。如果它不響應命令，則無話可說。
這往往感覺很像集中式系統
每一個改變程式碼甚至重要參數（價格？）的機會都可能重新引入中心化。思考這個問題的一個很好的起點是“誰來決定？”
為權威使用者或白名單保留某些功能並不少見，這幾乎總是某種程度的集中決策。一個例外可能是，當該使用者本身是一個涉及更包容、更民主的過程的契約時——應用程序承認一個全能的使用者，但該使用者只表達了法定人數的參與者的集體意願。
任何給定功能的治理設計和升級可能性的可取性都需要逐案考慮。由於我們有能力產生集中的權威、完全分散的進化或介於兩者之間的東西，因此考慮權衡並證明每個決定的合理性是很重要的。
幾乎總是更可取的是專注於值得提升到永恆真理水平的過程，而不是鎖定模組化設計、代理和永恆儲存等可升級模式。在發布之前練習極端的質量保證也很重要。
希望能幫助到你。