🔢Transaction Data Structure
1. Transaction
1
Version
byte
Transaction version 1. May be empty: If Version < 0x09, the first byte of transaction is the second field 'TxType' and the ‘Version’ is empty 2. If transaction type >= 0x09, must have 'Version' and the value must >= 0x09
.2
TxType
byte
Transaction type
3
PayloadVersion
byte
Transaction payload version: Multiple payload versions can exist for the same transaction
4
Payload
Payload
Transaction payload: Different transactions have their own payloads to record unique information, generally used for transaction verification. There are many types of payloads for transactions, which are described separately in the following sections
5
Attributes
[]*Attribute
Transaction attribute: Used to fill in nonce and user data, now only 'Nonce' and 'Memo' are commonly used
6
Inputs
[]*Input
Transaction inputs: UTXOs used by current transaction
7
Outputs
[]*Output
Transaction outputs: New UTXOs of current transaction
8
LockTime
uint32
The lock time of this transaction
9
Programs
[]*Program
Transaction signature; includes code and parameter
2 Attribute
1
Usage
byte
The usage type of this attribute
2
Data
[]byte
The data of this attribute
3 Input
1
TxID
uint256
Reference transaction hash of this input
2
Index
uint16
Reference outpoint index of this input
3
Sequence
uint32
Sequence number
4 Output
1
AssetID
uint256
Asset type: Currently there is only one asset type in the mainchain: elaAsset
2
Value
int64
Output amount
3
OutputLock
uint32
Output lock of this output
4
ProgramHash
uint168
Output address
5
Type
byte
Output type, some output types may have output payload
6
Payload
OuputPayload
Output payload: Different outputs have their own payload to record unique information; currently, there are six types of outputPayloads : OTNone, OTVote, OTMapping, OTCrossChain, OTWithdrawFromSideChain and OTReturnSideChainDepositCoin OutputPayload is described in detail in the following sections
5 Program
1
Code
[]byte
Redemption script: The contract program code which will be run on VM or a specific environment
2
Parameter
[]Byte
Unlock script: The program code's parameter is the signature of this transaction
6 Payload
6.1 Coinbase Transaction
Coinbase transaction is the first transaction in the block created by miners, which is used to distribute miners’ rewards and DPoS profits. Coinbase transactions can only be spent after at least 100 blocks are confirmed. Miners can add additional information in the payload in Coinbase.
Coinbase structure is as follows：
Content
[]byte
coinbase tx extra data
notice:
transaction payload
coinbase
coinbase transaction paylaod
core/types/payload/coinbase.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.2 RegisterAsset Transaction
The mainchain only supports the ELA token - you can use this transaction to issue your own token on the Elastos chain. Each asset has a controller and total issued amount, which is somewhat similar to ERC-20 tokens on Ethereum. At present, the maichain only supports ELA as an asset, and this transaction is only used as an extension transaction of the asset.
6.2.1 RegisterAsset payload
Asset
Asset
asset details
Amount
Int64
total asset amount
Controller
[21]Uint8
asset controller
6.2.2 Asset
Name
String
asset name
Description
String
asset description
Precision
byte
asset precision
AssetType
byte
asset type
RecordType
byte
asset record type
notice:
transaction payload
RegisterAsset
RegisterAsset transaction payload
core/types/payload/registerasset.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.3 TransferAsset Transaction
This is the most basic and commonly used transaction on the mainchain and can be used to transfer ELA assets. The voting transaction of DPoS and CR are also based on this transaction by changing the transaction output structure. The last section will introduce the structure of the transaction output payload.
payload is NULL
notice:
transaction payload
TransferAsset
TransferAsset transaction payload
core/types/payload/transferasset.go
output payload
OTNone/OTVote/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/vote/mapping/crosschain/withdraw/returnsidechaindeposit.go
6.4 SideChainPow Transaction
SideChainPow transaction, created by the cross-chain arbiter on duty and sent to the mainchain through RPC, aims to transfer the consensus of the mainchain to the sidechain of PoW to generate block: save the information of the sidechain in the mainchain, and record the information of the sidechain to the chain through the consensus of the mainchain.
In turn, this ensures the irreversibility of the sidechain, or transferring the computing power of the mainchain to the sidechain. The mainchain will verify whether the initiator of the SideChainPow transaction is the current cross-chain arbiter on duty. If the transaction is not packaged in time due to network and other problems, the old SideChainPoW transaction will be deleted from the trading pit because the verification fails, which means that the sidechain generating speed of PoW will be less than or equal to that of the mainchain and will not exceed that of the mainchain. At present, the realization of the sidechain is also changing to non-PoW sidechain, including the only PoW side chain that will be abandoned later.
The SideChainPoW structure as following：
SideBlockHash
[32]uint8
side chain block hash
SideGenesisHash
[32]uint8
side chain genesis hash
BlockHeight
uint32
side chain block height
Signature
[]byte
arbiter signature
notice:
transaction payload
SideChainPow
SideChainPow transaction payload
core/types/payload/sidechainpow.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.5 RechargeToSideChain Transaction
This is sent by the cross-chain arbiter on duty to the sidechain when it senses that there is a cross-chain transaction in the mainchain, which contains Merkel Proof, the mainchain transaction hash, and other information. After receiving this transaction, the sidechain will create the corresponding sidechain currency. This transaction doesn'texist in the mainchain but is used by the sidechain of the old version of PoW.
The PayloadRechargeToSideChain structure is as follows：
MerkleProof
[]byte
mainchain merkle proof
MainChainTransaction
[]byte
mainchain transaction details
MainChainTransactionHash
uint32
mainchain transaction hash
notice:
transaction payload
PayloadRechargeToSideChain
PayloadRechargeToSideChain transaction payload
Elastos.ELA.SideChain/types/payloadrechargetosidechain.go
6.6 WithdrawFromSideChain Transaction
This therefers to the transaction created by cross-chain arbiter and sent to the mainchain when it monitors the request of sidechain withdrawal. This transaction must be signed by 2/3 or more arbiters to ensure the reliability of withdrawal. Recharge and withdrawal are the implementation of two-way anchoring. The cross-chain arbiter obtains the transaction information of the sidechain through RPC. When it's found that there's a need to withdraw, the cross-chain arbiter on duty creates a multi-signature transaction and initiates a multi-signature withdrawal request. Other cross-chain arbiters verify this transaction and return signatures. When 2/3 of signatures are collected, the transaction will be sent to the main chain through RPC.
The WithdrawFromSideChain structure is as follows：
BlockHeight
uint32
withdraw sidechain height
GenesisBlockAddress
string
sidechain genesis block hash
SideChainTransactionHashes
[][32]uint8
side chain transaction hashes
notice:
transaction payload
WithdrawFromSideChain
WithdrawFromSideChain transaction payload
core/types/payload/withdrawfromsidechain.go
output payload
OTWithdrawFromSideChain
output payload type
core/types/outputpayload/withdraw.go
6.7 TransferCrossChainAsset Transaction
This is created by the user when the mainchain transfers money to the sidechain. It's two-way anchored with the WithdrawFromCrossChain transaction. When users need to recharge ELA to the sidechain, they need to build this transaction to transfer ELA to the frozen address beginning with X. Cross-chain arbiter will monitor this transaction and then send the transaction information to the sidechain. When making cross-chain transfer, you need to fill in the correct X-start address generated by genesishash of the sidechain and transfer the coins to the X-start address on the mainchain. The address starting with X can only be retrieved by a cross-chain arbiter with multiple signatures - thus, if the address is wrong, the money can’t be retrieved.
The TransferCrossChainAsset structure is as follows：
CrossChainAddresses
[]string
deposit sidechain address
OutputIndexes
[]uint64
spend mainchain output index
CrossChainAmounts
[]int64
deposit cross chain amount
notice:
transaction payload
TransferCrossChainAsset
TransferCrossChainAsset transaction payload
core/types/payload/transfercrosschainasset.go
output payload
OTCrossChain
output payload type
core/types/outputpayload/default.go
6.8 RegisterProducer Transaction
This is created by the user who needs to run for the supernodes. It's used to register a node as a DPoS node to participate in the main chain block generation consensus and obtain the block and voting profits - it needs to deposit at least 5000 ELA. The public key and nickname of the registered DPoS nodes are not allowed to be duplicated. After registering the DPoS nodes, the first 108 DPoS nodes can get the voting profits, and the top 23 DPoS nodes (as well as a random DPoS node) will be the elected nodes to generate block on consensus and can get the block generation profits.
OwnerPublicKey
[]byte
Owner public key
NodePublicKey
[]byte
Public key nodes
NickName
string
NickName
Url
string
Url to show detail information of DPoS node
Location
uint64
The location of DPoS node
NetAddress
string
The network address
Signature
[]byte
Signature
notice:
transaction payload
ProducerInfo
RegisterProducer transaction payload
core/types/payload/producerinfo.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.9 CancelProducer Transaction
This needs to be created by the user who registered the DPoS nodes, and is used to cancel the existing DPoS nodes. The deposit can only be retrieved after the cancellation is successful.
OwnerPublicKey
[]byte
Owner public key
Signature
[]byte
Signature
notice:
transaction payload
ProcessProducer
CancelProducer transaction payload
core/types/payload/processproducer.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.10 UpdateProducer Transaction
It needs to be created by the user who has registered the DPoS nodes and is used to modify the DPoS nodes information, including modifying the NodePublicKey to change the current node publickey and other information. After changing the NodePublicKey, the DPoS nodes participating in consensus will not be updated until the second round - that is, after the operating DPoS node is switched, the DPoS node will not be elected until the second round.
OwnerPublicKey
[]byte
Owner public key
NodePublicKey
[]byte
Public key nodes
NickName
string
Nick name
Url
string
Url to show detail information of DPoS node
Location
uint64
The location of DPoS node
NetAddress
string
The network address
Signature
[]byte
Signature
notice:
transaction payload
ProducerInfo
UpdateProducer transaction payload
core/types/payload/producerinfo.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.11 ReturnDepositCoin Transaction
This is created by a user who has registered with DPoS nodes and is used to retrieve the deposit of DPoS nodes. At present, there are two situations in which this transaction can be sent to retrieve the deposit. The first is that the deposit higher than 5000 ELA, then the exceeding part can be retrieved at any time. The second is that part of the deposit (without the fine part) can be retrieved after the DPoS node is canceled. It's not limited to retrieve all the deposit at once, and it can be operated several times. But a small amount of service charge will be deducted from the user’s available funds for each operation.
payload is NULL
notice:
transaction payload
ReturnDepositCoin
ReturnDepositCoin transaction payload , it is a empty struct
core/types/payload/returnpledgecoin.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.12 ActivateProducer Transaction
This is a transaction of activating the DPoS nodes, which is created by the user who has registered the DPoS nodes - however, the nodes have become inactive. It's used to activate the current DPoS nodes to continue to participate in consensus and obtain the block generation and voting profits. When a node participates in the consensus abnormally, it will be set to inactive state, which doesn’t allow the nodes to block generation and voting profits. Thus, it's necessary to adjust the configuration or check the node state to ensure that it can run normally and stably, then send an activation transaction to activate the nodes.
The ActivateProducer Structure is as follows：
NodePublicKey
[]byte
Public key nodes
Signature
[]byte
The signature
notice:
transaction payload
ActivateProducer
0x0d
Activate INACTIVE or illegal DPOS to receive orders
core/types/payload/activateproducer.go
output payload
OTNone/None
Transaction version greater than 9 type 'OTNone', otherwise 'none'
core/types/outputpayload/default.go
6.13 IllegalProposalEvidence Transaction
Illegal proposal evidence is confirmed by the block. The transaction is automatically generated by the mainchain. When the DPoS nodes participate in consensus, and the same consensus view initiates a proposal to confirm the block for different blocks, other nodes will automatically generate IllegalProposalEvidence transaction when they discover the illegal actions, and the illegal information of the DPoS nodes will be on the chain. After that, the illegal DPoS will be set to illegal state, and a certain deposit will be deducted.
DPOSIllegalProposal
Evidence
ProposalEvidence
evidence
CompareEvidence
ProposalEvidence
Evidence for reference
hash
common.Uint256
The hash
ProposalEvidence
Proposal
DPOSProposal
The proposal
BlockHeader
[]byte
Block head
BlockHeight
uint32
Block height
DPOSProposal
Sponsor
[]byte
The originator
BlockHash
common.Uint256
Block the hash
ViewOffset
uint32
ViewOffset
Sign
[]byte
The signature
hash
common.Uint256
The hash
notice:
transaction payload
IllegalProposalEvidence
0x0e
Activate INACTIVE or illegal DPOS to receive orders
core/types/payload/dposillegalproposals.go
output payload
OTNone/OTNone
Transaction version greater than 9 type 'OTNone', otherwise 'none'
core/types/outputpayload/default.go
6.14 IllegalVoteEvidence Transaction
Illegal vote evidence is confirmed by the block and automatically generated by the mainchain. When the DPoS nodes participate in consensus, and the same consensus view both agrees and rejects the block confirmation proposal, other nodes will automatically generate IllegalVoteEvidence transaction when they discover the illegal actions. The illegal information of the DPoS nodes will be on the chain. After that, the illegal DPoS will be set to illegal state, and a certain deposit will be deducted.
DPOSIllegalVote
Evidence
VoteEvidence
Polling evidence
CompareEvidence
VoteEvidence
Voting evidence reference
BlockHeight
uint32
Block height
hash
common.Uint256
The hash
VoteEvidence
ProposalEvidence
ProposalEvidence
Bill evidence
Vote
DPOSProposalVote
vote
ProposalEvidence
Proposal
DPOSProposal
The proposal
BlockHeader
[]byte
Block head
BlockHeight
uint32
Block height
DPOSProposalVote
ProposalHash
common.Uint256
Proposal to hash
Signer
[]byte
The signer
Accept
bool
Confirm the status
Sign
[]byte
The signature
hash
common.Uint256
The hash
notice
transaction payload
IllegalVoteEvidence
0x0f
Blocks identify evidence of wrongdoing in consensus voting on proposals
core/types/payload/dposillegalvotes.go
output payload
OTNone/None
Transaction version greater than 9 type 'OTNone', otherwise 'none'
core/types/outputpayload/default.go
6.15 IllegalBlockEvidence Transaction
Illegal forking evidence is confirmed by the block. The transaction is automatically generated by the mainchain. When the nodes receive different confirmation blocks at the same height and the view in the confirmation information are the same, it's considered that most of the on-duty DPoS nodes are trying to jointly commit to build forked blocks illegally, and the nodes will automatically generate IllegalBlockEvidence transaction, and the illegal information of the DPoS nodes will be on the chain. After that, the illegal DPoS will be set to illegal state, and a certain deposit will be deducted.
DPOSIllegalBlocks Structure is as follows：
CoinType
CoinType
Currency type
BlockHeight
uint32
Block height
Evidence
BlockEvidence
The Evidence
CompareEvidence
BlockEvidence
Evidence for reference
hash
common.Uint256
The hash
BlockEvidence
Header
[]byte
Block head
BlockConfirm
[]byte
Confirm the block
Signers
[][]byte
The signature
hash
common.Uint256
The hash
notice:
transaction payload
IllegalBlockEvidence
0x10
Block block consensus bifurcation block evil evidence
core/types/payload/dposillegalblocks.go
output payload
OTNone/None
Transaction version greater than 9 type 'OTNone', otherwise 'none'
core/types/outputpayload/default.go
6.16 InactiveArbitrators Transaction
Batch Inactive DPoS nodes transaction, which is a multi-signature transaction automatically constructed by the on-duty DPoS nodes, is used to put some DPoS nodes into inactive state according to the consensus participation, so as to improve the service quality of super nodes. This transaction has been obsolete and no longer used in the latest version.
InactiveArbitrators payload：
Sponsor
[]byte
the public key of sponsor.Must be one of the CR.
Arbitrators
[][]byte
the public keys of Arbitrators who will be inactived.
BlockHeight
uint32
main chain height.
notce:
transaction payload
InactiveArbitrators
InactiveArbitrators transaction payload
core/types/payload/inactivearbitrators.go
output payload
OTNone/无
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.17 NextTurnDPOSInfo Transaction
This is automatically built by the on-duty DPoS nodes, is used to record which super nodes are working at a certain height of the mainchain, including CR list and ordinary DPoS node list. Because the sidechain needs to know which supernodes are working at a certain height of the mainchain. This transaction is used to record super node information on the mainchain.
NextTurnDPOSInfo payload：
WorkingHeight
uint32
the effective height
CRPublicKeys
[][]byte
the node public keys of CR node
DPOSPublicKeys
[][]byte
the node public keys of DPoS node
notice:
transaction payload
NextTurnDPOSInfo
NextTurnDPOSInfo transaction payload
core/types/payload/nextturndposInfo.go
output payload
OTNone/none
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.18 RecordProposalResult Transaction
This is automatically generated on the chain and used to record the final consensus result of the proposal. For the side chain gets the status of the proposal through spv. At present, it is mainly used for DID short name reservation, activation and change proposal result record of short name rate. The purpose is to facilitate side-chain SPV to obtain proposal results and provide query interface.
RecordProposalResult payload：
RecordProposalResult
[]ProposalResult
The results of proposals
ProposalResult:
ProposalHash
common.Uint256
proposal hash
ProposalType
[][]CRCProposalType
proposal type
Result
[][]bool
result of proposal
notice:
transaction payload
ProposalResult
RecordProposalResult transaction payload
core/types/payload/customidresult.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.19 RegisterCR Transaction
It's constructed by users who need to participate in the CR campaign. After registration, they will become CR candidates. Candidates will accept users’ votes, and the top-ranked ones can become super nodes to participate in consensus. Registered CR candidates need at least 5000 ELA deposit, which will be deducted when the nodes are illegal or have abnormal consensus.
CRInfo payload：
Code
[]byte
code of CR
CID
[][]common.Uint168
cid of CR
DID
[][]common.Uint168
did of CR
NickName
string
nickname of CR
Url
string
urlto show information of CR
Location
uint64
location of CR node
Signature
[]byte
signature of this payload by CR
notice:
transaction payload
RegisterCR
CRInfo transaction payload
core/types/payload/crinfo.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.20 UnregisterCR Transaction
It's created by a user who has registered as a CR candidate and used to cancel it, and the deposit can only be retrieved after the cancellation. After the campaign is over, the elected CR can’t be cancelled. The deposit of the elected CR can only be retrieved after the CR is impeached or the inaugural period is over. Unelected CR nodes can directly retrieve deposit without canceling CR candidates.
CID
common.Uint168
CID of CR
Signature
[][][]byte
Signature of CR
notice:
transaction payload
UnregisterCR
UnregisterCR transaction payload
core/types/payload/unregistercr.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.21 UpdateCR Transaction
This is created by the owner of the CR nodes and used to modify the related information of the CR nodes.
CRInfo payload：
Code
[]byte
code of CR
CID
[][]common.Uint168
cid of CR
DID
[][]common.Uint168
did of CR
NickName
string
nickname of CR
Url
string
urlto show information of CR
Location
uint64
location of CR node
Signature
[]byte
signature of this payload by CR
notice:
transaction payload
UpdateCR
CRInfo transaction payload
core/types/payload/crinfo.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.22 ReturnCRDepositCoin Transaction
The transaction of deposit retrieving of CR nodes, which is created by the owner of CR nodes and used to withdraw the deposit. On the chain, it's allowed to withdraw the deposit for many times, and the part exceeding 5000 ELA can be taken away. After losing the election or the change of CR, part of the deposit (without the fine part) can be retrieved. The status of the deposit nodes will be changed to the Returned status.
The current proposal category codes are as follows:
（00）Ordinary CRC proposal（00）
（00）Ordinary proposal（00）
0x0000
For general transactional proposal issuance
ELIP（01）
ELIP（00）Standards track ELIP（00）
0x0100
Used to describe the changes in the design and implementation of Elastos infrastructure. Refer to the description of ELIP types in ELIP-1.
ELIP（01）Process ELIP (01)
0x0101
ELIP is used to describe the process definition or process change related to Elastos. Refer to the description of ELIP types in ELIP-1.
（02）Information ELIP (02)
0x0102
Used to describe the design problems of Elastos, or to provide general guidance or information to Elastos community. Refer to the description of ELIP types in ELIP-1.
（02）Code upgrade (02)
（00）ELA main chain code upgrade (00)
0x0200
Used to upgrade the ELA main chain code.
（01）DID side chain code upgrade (01)
0x0201
Used to upgrade the DID side chain code.
(02)ETH side chain code upgrade (02)
0x0202
Used to upgrade the ETH side chain code.
（04）ELA main chain (04)
（00）Election of the SecretaryGeneral (00)
0x0400
Used to nominate the Secretary General of CR Committee.
（01）Change the person in charge of the proposal (01)
0x0401
Used to realize the second method of replacing the person in charge of proposal described in section 7.7 of CRC white paper.
（02）Proposal termination (02)
0x0402
Used to realize the termination method of proposal described in section 7.9 of CRC white paper when the proposal cannot or should not be continued.
（10）Register the side chain (10)
0x0410
Used to register a piece of side chain information on the main chain.
（05）DID side chain (05)
（00）Reserved customized ID (00)
0x0500
Used to specify the customized ID that the DID side chain needs to reserve.
（01）Initiate customized ID (01)
0x0501
DIDCustomized ID for initiating reservation in DID side chain.
（02）Customized ID rate (02)
0x0502
Specify the customized ID transaction base rate for DID side chain.
payload is NULL
notice:
transaction payload
ReturnCRDepositCoin
ReturnDepositCoin transaction payload, is empty
core/types/payload/returnpledgecoin.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.23 CRCProposal Transaction
Next is the CRC proposal co-chain transaction, which is signed and launched to the chain by CR members and used for issuing proposal application. After the proposal is on the chain, it needs a 7-day CR review period and a 7-day referendum period. The CR review period is for 12 CR members to vote in order to decide whether to allow the proposal to be passed, and the referendum period is for everyone to vote, and the proposal can only take effect after passing the review period and the referendum period. The details of the proposal, budget amount, etc. can be described in the proposal. At present, there are more than ten kinds of proposal categories, and the payload structure and signature rules of different categories may be different.
6.23.1 CRCProposal
ProposalType
uint16
type of proposal
CategoryData
string
proposal category
OwnerPublicKey
[]byte
proposal owner public key
DraftHash
[32]uint8
draft of proposal data hash
DraftData
[]byte
draft of proposal data
Budgets
[]Budget
budget info
Recipient
[21]uint8
receipt of budgets
TargetProposalHash
[32]uint8
processing proposal hash
ReservedCustomIDList
[]string
reserved custom did list
ReceivedCustomIDList
[]string
already received custom did list
ReceiverDID
[21]uint8
receiver of custom did
RateOfCustomIDFee
int64
register custom did fee
NewRecipient
[21]uint8
new recipient address
NewOwnerPublicKey
[]byte
new proposal owner public key
SecretaryGeneralPublicKey
[]byte
public key of secretary general
SecretaryGeneralDID
[21]uint8
did of secretary general
Signature
[]byte
owner signature of this proposal
NewOwnerSignature
[]byte
new owner signature of this proposal
SecretaryGeneralSignature
[]byte
Secretary General signature of this proposal
CRCouncilMemberDID
[21]uint8
cr did
CRCouncilMemberSignature
[]byte
cr signature of this proposal
UpgradeCodeInfo
*UpgradeCodeInfo
upgrade code info details
SideChainInfo
SideChainInfo
register sidechain details
hash
[32]uint8
proposal hash
Not all fields are used, different proposal type may use some fields of them, need to use this according to core/types/payload/crcproposal.go
6.23.2 Budget
Type
byte
budget type
Stage
byte
budget execution stage
Amount
int64
budget amount
6.23.3 UpgradeCodeInfo
WorkingHeight
uint32
upgrade code start height
NodeVersion
string
version of node
NodeDownLoadUrl
string
downloading location
NodeBinHash
[32]uint8
binary file hash
ForceUpgrade
bool
do we need force upgrade this protocol
6.23.4 SideChainInfo
SideChainName
string
sidechain name
MagicNumber
uint32
sidechain magic
GenesisHash
[32]uint8
sidechain genesis hash
ExchangeRate
int64
mainchain sidechain coin exchange rate
EffectiveHeight
uint32
sidechain start function height
ResourcePath
string
path of resources
notice:
transaction payload
CRCProposal
CRCProposal tx payload
core/types/payload/crcproposal.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.24 CRCProposalReview Transaction
This is created by CR committee members to vote on the proposal. You can choose to agree, refuse, or abstain from voting. If the CR members don't send comments on certain proposals, a certain percentage of deposit will be deducted according to the proposal handling ratio when the CR changes.
CRCProposalReview struct as following：
ProposalHash
[32]uint8
hash of this proposal
VoteResult
byte
vote result，0 approve，1 reject ，2 abstain
OpinionHash
[32]uint8
reviewer's opinion hash
OpinionData
[21]byte
reviewer's opinion data
DID
[]byte
reviewer's did
Signature
[]byte
proposal reviewer's signature
notice:
transaction payload
CRCProposalReview
CRCProposalReview transaction payload
core/types/payload/crcproposalreview.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.25 CRCProposalTracking Transaction
This is initiated by a CR committee member and the Secretary General, and is used to track the stages of the proposal, including recording the implementation progress of the proposal, confirming and paying money after the completion of the phased tasks of the proposal, and suspending the proposal, etc. The payload format of this transaction will be different for different proposal categories.
CRCProposalTracking struct as following：
ProposalHash
[32]uint8
hash of proposal
MessageHash
[32]uint8
proposal tracking message hash
MessageData
[]byte
proposal tracking message data
Stage
byte
proposal stage
OwnerPublicKey
[]byte
owner proposal public key
NewOwnerPublicKey
[]byte
new owner proposal public key
OwnerSignature
[]byte
owner proposal signature
NewOwnerSignature
[]byte
new proposal owner signature
ProposalTrackingType
byte
tracking type ：0 Common，1Progress，2Rejected，3Terminated，4ChangeOwner，5Finalized
SecretaryGeneralOpinionHash
[32]byte
Secretary General's Opinion hash
SecretaryGeneralOpinionData
[]byte
Secretary General's Opinion info
notice:
transaction payload
CRCProposalTracking
CRCProposalTracking交易payload
core/types/payload/crcproposaltracking.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.26 CRCProposalAppropriation Transaction
This is automatically constructed on the chain, and is used to transfer 10% of the funds from CR assets address to CR expenses address when the CR members change.
payload is NULL
Notice:
transaction payload
CRCProposalAppropriation
CRCProposalAppropriation transaction payload , it is a empty struct
core/types/payload/crcproposalappropriation.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.27 CRCProposalWithdraw Transaction
This is created by the proposal owner and used to apply for withdrawal of funds in the proposal stage. The withdrawal of money must be consistent with the money acceptance address specified in the proposal.
CRCProposalWithdraw is as following：
ProposalHash
[32]uint8
hash of proposal
OwnerPublicKey
[]byte
proposal owner public key
Recipient
[21]byte
withdraw address
Amount
int64
withdraw amount
Signature
[]byte
proposal owner signature of this proposal withdraw action
notice:
transaction payload
CRCProposalWithdraw
CRCProposalWithdraw transaction payload
core/types/payload/crcproposalwithdraw.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.28 CRCProposalRealWithdraw Transaction
It's automatically constructed on the chain and used to send ELA from CR operation address to a specific acceptance address according to the money withdrawn by application. The reason why this transaction exists is that the chain is UTXO model, and there will be conflict of UTXO usage when many people apply at the same time, so the withdrawal is changed to two steps. The first step is user application, and the second step is automatic appropriation on the chain.
CRCProposalRealWithdraw is as following：
WithdrawTransactionHashes
[][32]uint8
the proposal hashes which need to withdraw
notice:
transaction payload
CRCProposalRealWithdraw
CRCProposalRealWithdraw transaction payload
core/types/payload/crcproposalrealwithdraw.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.29 CRCAssetsRectify Transaction
Thisis automatically built on the chain and is used to merge UTXO with scattered CRC asset addresses into one UTXO. Because the mainchain is UTXO model, each block will issue a small amount of block generation rewards to CRC asset address. This part of the rewards system will increase with the time, and excessive UTXO will bring efficiency loss to the query on the chain, so it's important to automatically sort out the UTXO of CRC asset addresses on the chain.
payload is NULL
Notice:
transaction payload
CRAssetsRectify
CRCProposalRealWithdraw trasaction payload it is a empty struct
core/types/payload/crcassetsrectify.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.30 CRCouncilMemberClaimNode Transaction
This is the transaction of the operation node claim of CR committee members, which is initiated by the elected CR committee members in the claim period and used to specify the DPoS node information. Within two weeks after the election of CR members, they're required to claim the DPoS nodes. At this time, CR members need to build this transaction. If the transaction is not claimed within the specified time, after the claim period, the nodes will become inactive, and they will no longer have the block generation profits and voting rights of proposals, and it will be recovered after the CR members claim it.
CRCouncilMemberClaimNode struct as following：
NodePublicKey
[]uint8
dpos node public key
CRCouncilCommitteeDID
[21]uint8
did of cr
CRCouncilCommitteeSignature
[]byte
cr council member signature of this struct
notice:
transaction payload
CRCouncilMemberClaimNode
CRCouncilMemberClaimNode transaction payload
core/types/payload/crcdposmanagement.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.31 RevertToPOW
The transaction degenerates into block generation of PoW consensus, which is automatically built on the chain and used to change the DPoS consensus on the chain into PoW consensus. There are three reasons for the reversion of this transaction. The first one is because there is no new block of consensus for 12 hours; the second is that PPoS nodes are insufficient; the third is that there are not enough CR members to claim nodes in the claim period. After degenerating into PoW consensus, there may be more forking reorganization. Under PoW consensus, users are only allowed to create a few transactions such as voting and activation. The purpose is to prevent people from using forking to do illegal actions. After reverting to PoW, the user can create the following transactions:
1. Registering transactions of DPoS nodes
2. Voting transactions of DPoS nodes
3. Activating transactions after the DPOS nodes are inactive
4. Registering transactions of CR members
5. Voting transactions of CR members
6. Activating transactions after CR members are inactive
Certainly, automatically generated transactions on the chain are allowed.
RevertToPOW payload:
Type
byte
Causes of degeneration to POW: NoBlock, NoProducers or NoClaimDPOSNode
WorkingHeight
uint32
Main chain height when officially in effect
notice:
transaction payload
RevertToPOW
RevertToPOW transaction payload, transaction type: 0x41
core/types/payload/reverttopow.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.32 RevertToDPOS
Transaction of reverting the block generation of DPoS consensus, which is automatically built on the chain and used to change the PoW consensus to the DPoS consensus. After the chain degenerates into PoW, it will check the current number of DPoS nodes and directly connected network conditions after each block is packed to see if the conditions for reverting are met. When the conditions are met, it will automatically generate a reverting transaction, and specify that it will be reverted as DPoS block generation at a certain main chain height.
WorkHeightInterval
uint32
Revert to DPoS when this transaction has more than WorkHeightInterval confirms
RevertToPOWBlockHeight
uint32
Record the height of last RevertToPOW transaction
notice:
transaction payload
RevertToPOW
RevertToDPOS transaction payload, transaction type: 0x42
core/types/payload/reverttodpos.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
6.33 ReturnSideChainDepositCoin
The return transaction of cross-chain recharge, which is generated by multi-signature of cross-chain arbiter and sent to the mainchain through RPC, is used to return the amount of cross-chain recharge transaction that fails to recharge under special circumstances to the user to prevent the loss of funds. Here, we mainly focus on the ESC sidechain recharge transaction. When the execution of the sidechain contract fails due to the error information written by the user in the DATA field of the transfer data in the transaction, the cross-chain arbiter will generate this transaction by multiply signatures.
payload is NULL
Notice:
transaction payload
ReturnSideChainDepositCoin
ReturnSideChainDepositCoin transaction payload , it is a empty struct, transaction type: 0x51
core/types/payload/returnsidechaindepositcoin.go
output payload
OTNone/null
tx version bigger than 9 then OTNone，otherwise null
core/types/outputpayload/default.go
7 OutputPayload
7.1 OTNone
OTNone indicates there is no payload for this output.
output payload is NULL
7.2 OTVote payload
OTVote indicates the output payload is a vote.
7.2.1 VoteOutput
Version
byte
VoteOutput version
Contents
[]VoteContent
VoteOutput content
7.2.2 VoteContent
VoteType
byte
vote type
CandidateVotes
[]CandidateVotes
candidate votes details
7.2.3 CandidateVotes
Candidate
[]byte
candidate public key
Votes
int64
candidate votes
7.3 OTMapping
OTMapping indicates the output payload is a mapping.
Mapping structure as following：
Version
byte
Version indicates the version of Mapping payload
OwnerPublicKey
string
OwnerPublicKey is the owner public key of the main chain producer
SideProducerID
int64
SideProducerID indicates a piece of data represent the identity of the side chain producer, whether it is a public key or address etc
Signature
[]byte
Signature represents the signature of the mapping payload content
7.4 OTCrossChain payload
OTCrossChain indicates the output payload is cross chain information.
CrossChainOutput structure as following：
Version
byte
crosschain transfer output version
TargetAddress
string
crosschain transfer output target address
TargetAmount
int64
crosschain transfer output amount
TargetData
[]byte
rosschain transfer extra info data
7.5 OTWithdrawFromSideChain payload
OTWithdrawFromSideChain indicates the output payload is withdraw from side chain information.
Withdraw structure as following：
Version
byte
withdraw version
GenesisBlockAddress
string
withdraw sidechain genesis block address
SideChainTransactionHash
[32]uint8
side chain hash
TargetData
[]byte
transaction extra data
7.6 OTReturnSideChainDepositCoin
OTReturnSideChainDepositCoin indicates the output payload is return side chain deposit coin.
ReturnSideChainDepositCoin structure as following:
Version
byte
withdraw version
GenesisBlockAddress
string
withdraw sidechain genesis block address
DepositTransactionHash
[32]uint8
the hash of DepositToSideChain transaction
Last updated