以太坊智能合約的生命周期
Ethereum Smart Contract Lifecycle
最近在寫一個募資合約時，發現自己對合約的生命周期還不是很了解，該用一個合約管理所有發起的募資，還是一個募資發起一個合約呢？
因此查詢了官網跟幾文章，然後在 testnet 上測試了一下。
以物件導向來比喻
以物件導向來比喻的話，可以把一個 contract 想像成一個 class，contract 可以被多次部署在網路上，每個實體都會有不同的地址，這個地址以後可以用來和這個地址指定的合約實體交互。因此每個部署的合約可以想成是物件導向的物件實體，每個合約實體都有自己的狀態(內部永久性的資料)。
合約的建構函數在合約部署到網路上時被呼叫，這也是唯一次被呼叫。所以，所有的初始化都應該在建構函數裡，在部署時只被執行一次。
在建立完合約之後，會有一個合約地址可以使用，在合約的有效期限之內可以用來和這個合約實體交互。
可以在合約內透過調用一個包括 selfdestruct 的函數來銷毀合約，這個函數就類似於物件導向裡面解構函數 destructor 的概念。
多合約
如果你的方案需要一個以上的合約來執行任務，就必需獨立地部署每個合約。A合約跟B合約溝通的唯一方法就是知道 B合約的地址。
如果 A合約需要跟不同的 B合約實體進行交互，在調用相關函數時必須傳入B合約實體的地址。如果A合約只跟一個B合約實體通訊，直接在A合約建構函數裡傳入B合約的實體地址，讓A合約存為變數即可。
訊息傳送者的地址
如果A合約裡的A函數, 調用B合約裡的B函數，在B函數的環境裡 msg.sender 就是 A合約的地址，如果你想在B函數裡面確定交易的發起者，應該使用 tx.origin。如果你從 A函數裡調用同樣是A合約的 A1函數， msg.sender 就是發起交易的地址跟 tx.origin 一樣。
結論
對於我現在這個募資項目來說，一個合約實體等同於一個獨立的募資，顯然比較合理。然後再用其他方式來管理這些合約實體，比如說一個管理類別的合約。
转载请注明原文链接：以太坊智能合約的生命周期 Ethereum Smart Contract Lifecycle
