https://developers.eos.io/welcome/latest/protocol/transactions_protocol

經(jīng)過這幾天對共識協(xié)議的完整翻譯和梳理元潘，一個最大的感受就是收獲大，但確實費時費力。不過，總體來說還是值得的抽米。

原文是transaction太伊，更傾向翻譯成交易鲤桥，可能有地方叫事務蚯嫌。

action之前一直翻譯成行為卑吭，最近翻閱一些資料后芽淡，應該翻譯成操作更合適。

1 概述

操作（action）是指在一個智能合約中的原子行為豆赏。在之前的實戰(zhàn)例子中也可以感受到挣菲，智能合約就是由多個action構(gòu)成富稻，用戶可以通過cleos push action命令執(zhí)行某合約中的某個action。從更高層次看白胀，去中心化應用中椭赋，交易定義一組被原子性執(zhí)行的actions。與數(shù)據(jù)庫中事務的概念類似或杠，交易中的一組actions必須按照預先定義好的順序哪怔，一個接一個的執(zhí)行，要么都成功向抢，要么都失敗认境。在交易失敗的情況下，為了維護交易的原子性和完整性挟鸠，需要將區(qū)塊鏈的狀態(tài)恢復到執(zhí)行交易前的狀態(tài)叉信。這保證了在故障點之前執(zhí)行的任何action都不會產(chǎn)生任何副作用。

1.1 操作（action）

操作能被一個或多個之前在區(qū)塊鏈上創(chuàng)建的actor授權(quán)艘希。個人理解硼身，這里的actor應該比account更細粒度，一個account可能有多個actor枢冤。即具有特定權(quán)限的actor可以指定誰執(zhí)行某操作鸠姨。在一個智能合約中，操作即可以被顯式創(chuàng)建淹真，也可以被隱式創(chuàng)建（內(nèi)聯(lián)操作）讶迁。

對于任何給定的actor:action對，最多有一個顯式關(guān)聯(lián)的最小權(quán)限（不理解）核蘸。如果沒有顯式最小權(quán)限巍糯，則隱式默認為actor@active。

每個actor都可以獨立地為給定的操作設置自己的最低權(quán)限客扎。此外祟峦，EOSIO軟件中有一個復雜但靈活的授權(quán)結(jié)構(gòu)，允許actor代表其他帳戶執(zhí)行操作（push action）徙鱼。因此宅楞，需要檢查是否為某個actor授權(quán)執(zhí)行某操作。

在一個交易中袱吆，有兩種類型的操作厌衙，他們的主要區(qū)別就是被執(zhí)行的方式不同：

顯式操作：在已簽名的交易中顯式出現(xiàn)

隱式操作（內(nèi)聯(lián)操作）：作為處理交易的一個副作用（side effect），例如通知绞绒？

和顯式操作一樣婶希，隱式操作也被定義在智能合約中。關(guān)鍵的區(qū)別在于蓬衡，內(nèi)聯(lián)操作不不會在網(wǎng)絡傳播并最終包含在塊中的實際交易中喻杈，他們是隱式的彤枢。

1.1.1 顯式操作

顯式操作包含在組成交易的實際操作列表中。在被放到交易里面之前筒饰，顯式操作被實現(xiàn)為具體的操作實例缴啡。顯式操作還包含實際的負載數(shù)據(jù)(如果有的話)，這些數(shù)據(jù)和操作相關(guān)聯(lián)龄砰，且作為交易的一部分盟猖。

1.1.2 隱式操作

隱式(內(nèi)聯(lián))操作是在一個交易中被顯式操作（即調(diào)用者）調(diào)用而產(chǎn)生的讨衣，該交易需要隱式操作來執(zhí)行一個操作换棚，以便顯式操作（即調(diào)用者）繼續(xù)進行。正因這樣反镇，內(nèi)聯(lián)操作和調(diào)用者是工作在相同的作用域和權(quán)限下的固蚤。因此，內(nèi)聯(lián)操作可以確保和調(diào)用者在同一個交易中執(zhí)行歹茶。

1.2 智能合約

在EOSIO系統(tǒng)中夕玩，智能合約是由一系列根據(jù)功能劃分的操作和這些操作所依賴的類型定義組成。即合約由操作和類型組成惊豺。因此燎孟，操作定義了合約的實際行為。一些行為是由標準的eosio合約實現(xiàn)尸昧，例如賬號創(chuàng)建揩页，為BP投票，通證轉(zhuǎn)賬等烹俗。應用開發(fā)者能通過在自定義的合約中創(chuàng)建自定義的操作來擴展爆侣、代替或者修改這些功能。另一方面幢妄，交易就是典型的在應用程序級創(chuàng)建的兔仰，智能合約和交易類似。

1.2.1 實現(xiàn)

智能合約是用c++語言實現(xiàn)的蕉鸳，需要從eosio::contract類繼承乎赴。操作就是合約類中的方法。交易是在eosio應用程序中動態(tài)生成的潮尝，通過交易實例實現(xiàn)榕吼。eosio處理每一個交易實例，跟蹤它的狀態(tài)：創(chuàng)建衍锚、簽名友题、驗證、執(zhí)行戴质。

2 交易實例

實例由交易頭度宦、操作實例列表和交易擴展踢匣。根據(jù)交易過期時間（交易被執(zhí)行的時候會計算出來），交易頭評估它需要包含的必要信息戈抄。（過期時間不一樣离唬，交易頭中信息還不一樣？）其他字段包括包含該交易的塊號（沒有找到；搿Ｊ漭骸！）裸诽，塊id前綴（用于防止跨鏈嫂用，跨分支攻擊，沒有找到Ｕ啥Ｖ龊！）埂蕊、CPU和網(wǎng)絡使用的上限往弓、以及延遲事務的秒數(shù)（如果適用）。交易實例如下示意圖蓄氧。

操作實例由常規(guī)操作或上下文無關(guān)的操作組成函似。簽名是在交易級別被創(chuàng)建和驗證的。也就是說單一行為不會做簽名的喉童。帳戶和權(quán)限會基于單個操作處理撇寞。

每個操作實例都包含一些信息，用于根據(jù)操作中指定的actor的權(quán)限級別（即actor@permission）和合約中為該操作指定的實際授權(quán)來驗證它是否可以執(zhí)行泄朴。

2.1 交易ID

每個交易實例對應著一個交易實體重抖，不同交易通過交易ID區(qū)分。交易ID是通過包含在交易實例中的基本信息經(jīng)過加密哈希處理后生成的祖灰。因此钟沛，交易ID是由交易頭，操作列表和交易擴展字段唯一決定的（這不是廢話嘛）局扶。交易實例后續(xù)可以被具化成簽名交易實例或打包交易實例恨统。

2.2 簽名交易實例

簽名的交易擴展了交易字段的基本內(nèi)容，包括對交易進行簽名的賬號生成的簽名信息三妈。還包括與交易實例中包含的上下文無關(guān)操作(如果有的話)相關(guān)的任何數(shù)據(jù)畜埋。只有被賬號簽名過的交易，才能準備被執(zhí)行和驗證畴蒲。

簽名交易字段如下：https://developers.eos.io/welcome/latest/protocol/transactions_protocol/#signed_transaction-schema

2.3 打包交易實例

被打包的交易里面悠鞍，是否壓縮是可選項。打包交易會將空間最小化模燥，形成EOSIO中最常見的交易類型咖祭。因此掩宜，當交易被推入一個塊時，不管是否壓縮么翰，它們都是打包交易牺汤。

打包交易字段如下：https://developers.eos.io/welcome/latest/protocol/transactions_protocol/#packed_transaction-schema

擴展

1、eosio是如何確認交易的原子性的浩嫌？

參考：https://www.zhihu.com/question/30272728

沒有找到eos如何做到的檐迟，找到普通數(shù)據(jù)庫如何做到的。

為了實現(xiàn)原子性码耐，需要通過日志：將所有對數(shù)據(jù)的更新操作都寫入日志追迟，如果一個事務中的一部分操作已經(jīng)成功，但以后的操作，由于斷電/系統(tǒng)崩潰/其它的軟硬件錯誤而無法繼續(xù)，則通過回溯日志换怖，將已經(jīng)執(zhí)行成功的操作撤銷役纹，從而達到“全部操作失敗”的目的。最常見的場景是金闽，數(shù)據(jù)庫系統(tǒng)崩潰后重啟纯露，此時數(shù)據(jù)庫處于不一致的狀態(tài)，必須先執(zhí)行一個crash recovery的過程：讀取日志進行REDO（重演將所有已經(jīng)執(zhí)行成功但尚未寫入到磁盤的操作代芜，保證持久性）埠褪，再對所有到崩潰時尚未成功提交的事務進行UNDO（撤銷所有執(zhí)行了一部分但尚未提交的操作，保證原子性）挤庇。crash recovery結(jié)束后钞速，數(shù)據(jù)庫恢復到一致性狀態(tài)，可以繼續(xù)被使用嫡秕。

2渴语、交易參數(shù)關(guān)系