github.com/hyperledger/burrow@v0.34.5-0.20220512172541-77f09336001d/docs/reference/transactions.md (about)

     1  # Transactions
     2  
     3  Burrow implements a number of transaction types. Transactions will be ordered by our consensus mechanism (Tendermint) and applied to our application state machine - 
     4  replicated across all Burrow nodes. Each transaction is applied atomically and runs deterministically. The transactions contain the arguments for an 
     5  [execution context](https://github.com/hyperledger/burrow/tree/main/execution/contexts).
     6  
     7  Our transactions are defined in Protobuf [here](https://github.com/hyperledger/burrow/blob/main/protobuf/payload.proto).
     8  
     9  Transactions can be built using our GRPC client libraries programmatically, via [burrow.js](js-api.md), or with `burrow deploy` - see our [deployment guide](deploy.md).
    10  
    11  ## TxInput
    12  
    13  | Parameter | Type | Description |
    14  | ----------|------|-------------|
    15  | Address | Address | The address of an account issuing this transaction - the transaction envelope must also be signed by the private key associated with this address |
    16  | Amount | uint64 | The amount of native token to transfer from the input to the output of the transaction |
    17  | Sequence | uint64 | A counter that must match the current value of the input account's Sequence plus one - i.e. the Sequence must equal n if this is the nth transaction issued by this account |
    18  
    19  
    20  ## CallTx
    21  
    22  Our core transaction type that calls EVM code, possibly transferring value. It takes the following parameters:
    23  
    24  | Parameter | Type | Description |
    25  | ----------|------|-------------|
    26  | Input | TxInput | The external 'caller' account - will be the initial SENDER and CALLER |
    27  | Address | *Address | The address 'callee' contract - the contract whose code will be executed. If this value is nil then the CallTx is interpreted as contract creation and will deploy the bytecode contained in Data or WASM |
    28  | GasLimit | uint64 | The maximum number of computational steps that we will allow to run before aborted the transaction execution. Measured according to our hardcoded simplified gas schedule (one gas unit per operation). Ensure transaction termination. If 0 a default cap will be used. |
    29  | Fee | uint64 | An optional fee to be subtracted from the input amount - currently this fee is simply burnt! In the future fees will be collected and disbursed amongst validators as part of our token economics system |
    30  | Data | []byte |  If the CallTx is a deployment (i.e. Address is nil) then this data will be executed as EVM bytecode will and the return value will be used to instatiate a new contract. If the CallTx is a plain call then the data will form the input tape for the EVM call |
    31  
    32  ## SendTx
    33  
    34  Allows [native token](reference/participants.md) to be sent from multiple inputs to multiple outputs. The basic value transfer function that calls no EVM Code.
    35  
    36  ## NameTx
    37  
    38  Provides access to a global name registry service that associates a particular string key with a data payload and an owner. The control of the name is guaranteed for 
    39  the period of the lease which is a determined by a fee.
    40  
    41  > A future revision will change the way in which leases are calculated. Currently we use a somewhat historically-rooted fixed fee, see the [`NameCostPerBlock` function](https://github.com/hyperledger/burrow/blob/main/execution/names/names.go#L83).
    42  
    43  ## BondTx
    44  
    45  This allows validators nominate themselves to the validator set by placing a bond subtracted from their balance.
    46  
    47  For more information see the [bonding documentation](reference/bonding.md).
    48  
    49  ## UnbondTx
    50  
    51  This allows validators remove themselves to the validator set returning their bond to their balance.
    52  
    53  ## BatchTx
    54  
    55  Runs a set of transactions atomically in a single meta-transaction within a single block
    56  
    57  ## GovTx
    58  
    59  An all-powerful transaction for modifying existing accounts.
    60  
    61  ## ProposalTx
    62  
    63  A transaction type containing a batch of transactions on which a ballot is held to determine whether to execute, see the [proposals tutorial](tutorials/8-proposals.md).
    64  
    65  ## PermsTx
    66  
    67  A transaction to modify the permissions of accounts.
    68  
    69  ## IdentifyTx
    70  
    71  When running a closed or permissioned network, it is desirable to restrict the participants.
    72  For example, a consortium may wish to run a shared instance over a wide-area network without
    73  sharing the state to unknown parties. 
    74  
    75  As Tendermint handles P2P connectivity for Burrow, it extends a concept known as the 'peer filter'.
    76  This means that on every connection request to a particular node, our app will receive a request to 
    77  check a whitelist (if enabled, otherwise allowed by default) - if the source IP address or node key is 
    78  unknown then the connection will be rejected. The easiest way to manage this whitelist is to hard code
    79  the respective participants in the config:
    80  
    81  ```toml
    82  [Tendermint]
    83    AuthorizedPeers = "DDEF3E93BBF241C737A81E6BA085D0C77C7B51C9@127.0.0.1:26656,
    84                          A858F15CD7048F7D6C1B310E016A0B8BA1D44861@127.0.0.1:26657"
    85  ```
    86  
    87  This can become difficult to manage over time, and any change would require a restart of the node. A more
    88  scalable solution is `IdentifyTx`, which allows select participants to be associated with a particular 
    89  'node identity' - network address, node key and moniker. Once enabled in the config, a node will only allow
    90  connection requests from entries in its registry.
    91  
    92  ```toml
    93  [Tendermint]
    94    IdentifyPeers = true
    95  ```
    96  
    97  For more details, see the [ADR](ADRs/adr-2_identify-tx.md).