# The Decracy Transaction Layer ### Intro This document represents the structure and functionality of the Decracy Transaction Layer(DTL) at a high level. Given the fact that Decracy is a DAG system, the DLT is tailor-made to achieve the best results for that environment. As transactions can be presented(broadcasted) at any given time on a DAG chain, they are validated as they arrive on the system. This is the main future of a DAG system that relies on the ordering of the transactions to identify the order of those incoming. For a transaction to be considered valid, on a very high level, it needs to be evaluated from the consensus layer driven by the validators on the network. When a transaction is received by a node, it first has to verify two other transactions before the original transaction can be validated. Those two transactions are chosen by an algorithm and they have to be nonconflicting. To avoid spam the node is forced to solve a small computational problem so it can broadcast the transaction. The algorithm here is like a weighed binary search system, where the weight is presented by the confidence that the system has for those transactions. Since a transaction is considered safe to be validated the avalanche consensus model comes in and validates the state with the validators by sampling them. The layer comprises two types of transactions, single and multi-parties transactions. Single transactions are transactions from a single address to another one and require to be signed by one private key, while multi-party transactions contain a signature that is aggregated from multiple parties. Signature aggregation is achieved by using the BLS signature scheme. Distributed Key Generation would be used to produce these keyshares. #### The Transaction Structure All transaction types of the layer are encapsulated within `RPC`(s). The system has a basic `Transaction` structure that, on it's data fields, represent the amount of tokens that it is about to execute and the `TransactionID` on the system. ```rust /// Decracy Token Transactions #[derive(Clone, Copy, Eq, PartialEq, Ord, PartialOrd, Hash, Serialize, Deserialize, Debug)] pub struct Transaction { /// Amount held in the transaction. pub amount: Token, /// Transaction ID. pub id: usize, } ``` The RPC is an Enum that enumerates either a `Request` or a `Response`. Nodes send a nd receive these RPCs, perform conensus on them, check it's va;idity with the netowrk and if all goes well, the Validators in the system execute them at the same time. ```rust #[derive(Clone, Serialize, Deserialize, Debug)] pub enum RPC { /// Request messages sent across the network Request(Request), /// Response messages sent across the network Response(Response), } ``` The `Request` is also an enum contains the transaction type that is requested to be executed. The Requests hold various variants of Transactions that the network allows to perform. The variant types hold informations like the address of the sender, the timestamp, a nonce for the small pow that is required to verify before sending a transaction(to mitigate attacks) and the hash of that pow calculation. The different types of Transactions originate in this enum and are encapsulated into an RPC and sent accross the network. ```rust pub enum Request { /// Transfer tokens from Node to other TransferTokens { /// Account to whom the token should be sent. account: [u8; 32], /// The transaction itself. transaction: Transaction, }, /// Create an Account on the Network CreateAccount(Account), /// Stake the node Staking { /// The account from which the node should be staked. account: [u8; 32], /// The amount to be staked. transaction: Transaction, . . . /// Execute the given smart contract ExecuteSmartContract { /// Hash of the smart contract hash: [u8; 32], }, } ``` ![](https://i.imgur.com/TBct3Rz.jpg) Every `Request` gets mapped one-on-one to a `Response` that is also an enum that contains the results to the executed `Request`. The Responses arise as a conclusion of validations at various stages, the first validator that picks up a `Request` verify the senders account's legality and legibility, and forwards the request as a `NetworkRPC` to the network. The network now runs a consensus for the request arrive at a result. The network will operate on a Wallet, only if all the conditions that are checked through the above mentioned flow are satisfied, therefore preventing further complications of refunding to a client. The clients then map their sent `Request`s to the incoming responses with the help of nonces that they had provided as a hash of their PoW calculations. ![](https://i.imgur.com/dgey56w.jpg) #### Types of Transactions enumarated with RPCs: ##### Transfer Transaction RPC The transfer transaction represents the most basic form of transaction in the system, that of moving Decracy `Tokens` from an address to another in the network. The `Request` would hold the _to_ address of the participating account the transaction itself. ```rust /// Transfer tokens from Node to other TransferTokens { /// Account to whom the token should be sent. account: [u8; 32], /// The transaction itself. transaction: Transaction, }, ``` ##### File Transaction The file transaction type represents a transfer/sharing of a files from one address to another and contains a hash of the file. It can also be modulated to be a broadcast to the network or a group of validators as well. ```rust ShareFile { /// The file to be shared on the network. file: Vec<u8>, /// Hash of the file. hash: [u8; 32], }, ``` ##### Verify File Transaction The verify file transaction represents a transaction to verify if a file exists in the system. As malicious users may validate a file and then erase it this transaction type ensures that there is a checking mechanism to mitigate that. ##### Deploy Transaction - (Implemented) The deploy transaction represents a transaction that deploys a smart contract and contains the hash of the smart contacts file and a optional deadline for the life of the smart contract. If no deadline is provided the contract will live for ever in the system. ##### Execution Transaction - (Implemented) The execution transaction represents the execution of a smart contract and contains the hash of the deployment of the smart contract, a collection of the function names that the contract contains, a byte array of the parameters of the contract and finally a gas field for the fees. ##### Slashing Transaction - (Not Implemented) The slashing transaction represents the slashing of a account in the case of misbehaviour with in the system. The strucure contains the account to be slashed, the amount to be slashed and the transaction hash of the reason of the slashing. ##### Stake Transaction - (Implemented) The stake transaction represents the transaction that stakes an amount on the system. Staking works by spawning a child account that holds the staked coins, the deadline of the staking period and the amount that will be staked. ##### Unstake Transaction - (Implemented) The unstake transaction represents the transaction that unstakes an amount on the system. It can be only created by the parent account and it contains the staking account and the hash of the staking transaction that locked the coins. ##### Asset Transaction ##### Reward Transaction - (Implemented) The reward transaction represents the transaction that rewards the participating accounts on network validation. It contains the account to be credited, the amount and the hash of the staking period that the account has staked. ##### Account Creation Transaction - (Implemented) The account creation transaction represents the transaction that creates a new account and contains the public key of the created account. ```rust /// Transaction Type represents all the transaction types on the layer pub enum TransactionType { Transfer, // Transfer transaction FileTransaction, // File transaction VerifyFileTransaction, // Verify a file transaction DeployTransaction, // Deploy smart contract transaction ExecutionTransaction, // Execution transaction SlashingTransaction, // Slashing transaction StakeTransaction, // Stake bonding transaction UnstakingTransaction, // Unstake transaction AssetTransaction, // Asset transaction RewardTransaction, // Rewarding transaction AccountCreation, // Account creation transaction } /// The main transaction structure pub struct Transaction { transaction_type: TransactionType, // The transaction type address: ID, // A 32 byte array representing the address timestamp: u128, // Time of creation nonce: u128, // The nonce of small pow hash: Hash, // The hash of the small pow signature: Signature, // The bls signature of the transaction signature_pub_keys: Vec<Pubkey>, // The public keys of the bls signature messages: Vec<Hash>, // The messages for the bls signature data: Vec<u8>, // The data of the underlying transaction type } /// Transfer Transaction Type represents /// the transfer value transaction type pub struct TransferTransaction { from: ID, // Sender address to: ID, // Receive address public_keys: Vec<Pubkey>, // Used to hide transaction amount amount: Vec<u8>, // Encrypted bytes of amount to transfer } /// File Transaction Type represents /// a transaction of a file pub struct FileTransaction { hash_of_file: Hash, // The hash of the file } /// Verify File Transaction Type represents /// a transaction to verify file transactions pub struct VerifyFileTransaction { hash_of_file_tx: Vec<Hash>, // The hash of the file } /// Deploy Transaction Type represents /// a smart contracts deployment transaction pub struct DeployTransaction { hash_of_file: Hash, // The hash of the smart contract file deadline: Option<Time>, // Time that smart contact dies // (Optional as we can have smart contracts that live for ever) } /// Execution Transaction Type represents /// a smart contacts execution transaction pub struct ExecutionTransaction { hash_of_deploy_tx: Hash, // The hash of the deployed smart contact transaction function_name: Option<String>, // The function name of execution function_parameters: Vec<u8>, // The parameters as encoded byte array gas: u128, // The gas amount } /// Slashing Transaction Type represents /// the slashing of a account due to a failed validation pub struct SlashingTransaction { account: ID, // Malicious account to be slashed amount: u128, // Amount to slash hash_of_tx_failed: Hash, // The hash of the transaction causing the slash } /// Stake Transaction Type represents /// the bonding transaction to stake coins pub struct StakeTransaction { staking_account: ID, // The account to hold the stake deadline: Option<Time>, // The deadline of the staking amount: u128, // The amount that is at staking } /// Unstake Transaction Type /// represents the unbonding transaction to unstake coins pub struct UnstakeTransaction { staking_account: ID, // The staking account that we want to unstake hash_of_staking_tx: Hash, // The hash of the staking transaction } /// Asset Transaction Type /// represents the asset transfer transaction type pub struct AssetTransaction { asset: Token, // The asset to be transfered initial_amount: u128, // The initial value min_stake_time: Time, // The minimum stake time min_fee: u128, // The minimum fee } /// Reward Transaction Type represents /// the rewarding transaction to the staking participants pub struct RewardTransaction { account: ID, // The account to be rewarded amount: u128, // The amount to be rewarded hash_of_staking_period: Hash, // The hash of the staking period } /// Account Creation Transaction Type represents /// a transaction that creates a new account pub struct AccountCreationTransaction { public_key: Pubkey, // The accounts pubkey } ```