Cardano Transaction Fees

Transcription

1 Cardano Transaction Fees Lars Brünjes May Introduction From the point of view of us, the creators of Cardano, we have two motivations for fees: Prevention of DDoS (distributed denial of service) attacks by making it prohibitively expensive for an attacker to spam the network with thousands of transactions. Providing incentives to slot leaders and input endorsers (see [3, 5.4]) to be online when the protocol requires them to be and to do their best to make the system run efficiently. These two items align nicely with the technical point of view of two degrees of freedom for the system: It can either lose a transaction or delay it, thus influencing the Q 1 of the system. This suggests that there should be two components to fees: A minimum fee for each transaction (which can be computed using the ideas from my document, looking at things like the transaction size and the past of the blockchain) and premium fees for better service. In order to prevent DDoS attacks, it will not be enough to use fees to prevent excessive block size growth, because even if spam transactions are prevented from getting into a block, they could still clog the network and/or the mempools. Therefore, fees should not only be considered when accepting a transaction into an endorsed input, but also when accepting a transaction into a mempool (and then relaying it to other nodes). Note that minimum fees must be non-zero in order to prevent DDoS attacks. Note also that minimum fees by themselves are not sufficient to prevent DDoS attacks in addition we need an explicit maximum lifetime of transactions, to guard against unintended flaws in the system (no system is perfect... ). 1 The term Q denotes the improper probability distribution of transaction processing times in the system, where improper refers to the fact that probabilities do not necessarily sum up to 1, allowing for the possibility of lost transactions 1

2 Such a maximum lifetime has the additional benefit of preventing transactions from getting stuck in the system forever without ever being included into a block. This could for example happen if the minimum fee level of the system rises, so that input endorsers always prefer newer transactions with higher fees and never include the old transaction with its lower fees into any block they create. The relation between the two degrees of freedom of the system and minimumand premium fees is that transactions whose fees are below the minimum get lost/ dropped from the system, and transactions with premium fees get better service / less delay, i.e. nodes do their best to get them into the blockchain quickly. Nodes will not relay transactions with insufficient fees, and slot leaders will try to maximize the amount of fees contained in the blocks they build. In addition to that, nodes will also try relaying transactions containing higher fees quicker. How nodes actually do that is an implementation detail. They could for example relay premium transactions to more of their peers. Our hope is that it will be an emergent property of the system that fees incentivize nodes to increase efficiency, throughput and performance. Note that there is a relation between the minimum fees and the maximum lifetime of a transaction: The minimum fees should be calculated in such a way that they are low enough to guarantee inclusion into the blockchain during the transaction s lifetime with a fixed, high probability. 2 How fees work technically Let us briefly review how fees work technically: A transaction contains a list of inputs and a list of outputs (where the inputs are normally outputs from previous transactions). The sum of amounts in the inputs must never be smaller than the sum of amounts in the outputs. It may be bigger, though, and the difference by definition is the transaction fee. Distribution of fees works as follows: All transactions in all blocks of a certain period (an epoch!?) are examined for their fees, and all of those fees are added up and put into a virtual pool. This pool is then divided equally (see 5.4 for details) between the slot leaders of that period. Note that in the Ouroboros paper [3], there is also the concept of input endorsers, who will also get part of the fee pool, but in the first iteration of Cardano, we will not have input endorsers their job is done by the slot leaders. How do the slot leaders actually get their share of the fee pool? This is implicit: There will be a new type of transaction input, which references a period (epoch) and which the slot leaders can use as input for their transactions. Every participant can check whether they are actually entitled to use that input by inspecting the blocks of that period and doing the fee calculation. 2

3 3 Refunds An exciting novel idea 2 is to give a refund on premium fees if premium service was not provided. This refund should depend smoothly on the premium paid and on the lateness of service. The difference between paid fee and refund may be allowed to drop below the minimum fee, but it must never be allowed to drop to zero. The beautiful thing here is that we think this can actually be done on a technical, system level, thus building ethics into the system : When calculating the transaction pool, each participant of the system can compare fees, issue dates and block creation dates to see whether a premium was paid and whether the transaction was included into a block swiftly enough. Thus one can subtract premium fees from the fee pool in case of delayed service, and only distribute the rest amongst the slot leaders. Even better, one can use the same mechanism as for the slot leaders (special input type which references the period/epoch) to allow transaction submitters to claim their refund. No transactions need to be created for this, refunds will just work implicitly by inspecting the data. 4 How other cryptocurrencies handle it 4.1 Bitcoin When building a block, the fee rate (in BTC/kB) of all available transactions is considered. Transactions with a fee rate below BTC/kB are dropped, the others are added to the block in decreasing order of fee rate until the maximum block size of 750 kb has been reached [1]. 4.2 Ethereum Classic Each transaction specifies a maximum number of gas and a maximum price for gas. Miners can decide freely whether they want to accept a transaction or not. If they do, they will execute the transaction and charge fees depending on the number of execution steps, provided those fees do not exceed the limits specified in the transaction [2]. 4.3 Litecoin The minimum transaction fee is LTC/kB, where the size of a transaction is rounded up to the next kb. Additionally, there is a penalty of LTC for each transaction output of less than LTC [4]. 2 Thank you, Neil Davies, for this excellent idea! 3

4 4.4 Monero It seems that transaction fees work similarly to Bitcoin (see 4.1), because they depend on transaction priority and size. However, in contrast to Bitcoin, there is no maximum block size in Monero, so that transactions are not competing with each other for inclusion in the next block [5]. 4.5 NEM The fee for a transaction is 0.1 % of the transaction amount [6]. 4.6 Ripple In Ripple, transaction fees are not paid to anybody, but instead burnt, thus decreasing the total amount of coins in the system on each transaction. There is a minimum transaction fee of XRP for standard transactions (the minimum fee is higher for non-standard transactions). Each Ripple node calculates a Load Cost, which depends on the current server load. If a transaction includes fees that are below this Load Cost, the node will reject the transaction and not propagate it to other nodes. Furthermore, there is an Open Ledger Cost, which equals the minimum fee, as long as the number of transactions included in the current block stays below an (adaptively changing) threshold. Once the threshold is reached, fees increase exponentially. If a transaction s fees are below the Open Ledge Cost, the transaction will not be included in the block. In that case, the node decides heuristically whether to reject or keep the transaction, based on the transaction s chances of being included in a later block [7]. 5 Mathematical Model 5.1 Notation and Definitions Definition 5.1. We will use the following notations: 1. Let N be the set of nodes in the system. 2. Let C be the set of all possible blockchains, i.e. the set of consistent, valid blocks starting at the genesis block g. 3. Let B g be the set of (potential) blocks, where a block consists of zero or more (but usually one) endorsed inputs. We have a function i : B N, which gives the slot in which a block was issued (note that i(g) = 0), and we have a function C P(B), c B c, mapping a chain to the contained blocks. 4

5 4. For c C and t, t N, let B c [t,t ] := { b B c t i(b) t } be the set of blocks from c issued between slots t and t. 5. Let I the set of (potential) (endorsed) inputs, where an input contains of an ordered collection of transactions. We have a function i : I N, which gives the slot in which an input was issued, and we have a function B P(I), b I b, mapping a block to the contained inputs. Note that b B : i I b : i(i) i(b). 6. For t N, let C t C be the subset of chains that contain blocks issued not later than in slot t: Note that we obviously have C t := { c C i(b c ) {0... t} }. C = t N C t. We also define C t for t < 0 by setting it to {{g}} in that case. With this extension, we still have C = t Z C t. 7. For N t t, we have a map C t C t, c c t := { b B c i(b) t }, induced by restricting chains to blocks that have been issued at slot t or earlier. We extend this map to t < 0 by setting c t := {g} in that case. 8. For n N and t N, let C n t C t be the blockchain actually observed by node n at slot t. 9. Let T be the set of (potential) transactions. We have maps s : T N, c : T [1, ), f : T (0, ) and i : T N, which give a transactions s size (in bytes), complexity (in multiples of the simplest possible transaction), contained fees (in ADA) and the slot it was issued in, respectively. 10. For t N, let T t := {tx T i(tx) = t} be the set of transaction issued in slot t. We then have T = t N T t. 5

6 11. For i I, let T i T i(b) be the set of transactions contained in i, and for b B, let T b T i(b) be the set of transactions contained in b. Note that T b i I b T i, but that this in general will not be an equality, because there may be conflicting transactions in the inputs of a block, in which case only the lexicographically first transaction counts as being in the block. 5.2 Minimum Fees Functions First of all, we need a function to calculate the minimum fees for a given transaction. Such a function should be allowed to depend on the blockchain, but it should also be computable by each node (which only sees its own, individual version of the blockchain). Definition 5.2. For N, define the set CT := t N C t T t, and consider the family of functions { } MF := mf : CT (0, ). Intuitively, a function in MF can look at the transaction and at the blockchain blocks in the past to determine the minimum transaction fees. For such a function mf MF and a node n N, define by mf n : T (0, ) mf n (tx) := mf(c n i(tx) i(tx), tx). (5.1) (Thus to evaluate mf n, node n looks at its local version of the blockchain, truncates it to slots before the transaction was issued, and then applies mf.) Remark 5.3. Note that mf n is computable by n, because it only uses data available to the node, namely the local blockchain and the transaction, as input. Note also that strictly speaking mf n is only well-defined for slots t which are not in the future, but we ignore this issue, because future transactions are by definition invalid and will be rejected and never processed further. Theorem 5.4. Let 0 be sufficiently large, let mf MF, let n, n N be nodes, and let tx T be a transaction. Then with high probability mf n (tx) = mf n (tx). 6

7 Proof. Because 0, the Common Prefix property of the system implies with high probability that C n t t = C n t t, and the desired equality follows from definition 5.2. In light of theorem 5.4, functions mf from the set MF (for sufficiently large ) and the induced local functions {mf n } n N are the right candidates for defining minimal fees functions that exhibit the properties we expect of such functions: They are sufficiently rich by being able to evaluate the blockchain, but they can also be independently computed locally by each node. To make such functions more tractable, we will consider a subset of MF : Definition 5.5. For N, let MF MF be the subset of functions mf that factorize as follows: 1 (s,c) CT C N (1, ) mf mf (0, ) (5.2) Those are functions which only look at a transaction s size and complexity (and at the blockchain) to determine the minimum fees. The set MF contains very interesting and highly sophisticated functions that use complex economical models and moving averages, but there are also very simple functions there: Definition 5.6. Let m (0, ) be a price per byte in ADA, and let mf m MF (for all ) be defined by mf m (c, s, x) := m s, which completely ignores the blockchain and transaction complexity, and which induces mf m : T (0, ), tx m s(tx). Picking a function from the family {mf m } m (0, ) as minimum fees function could be a good, pragmatic starting point for the first phase of Cardano. Definition 5.7. Minimum fee functions become more interesting when they actually do look at the blockchain (from slots in the past): 1. Let M be the following set of functions: M := { f : [0, 1] [1, ) f is monotonically increasing } 7

8 2. For a chain c C and slots t, t N, define 1 if B c [t,t ] = s c [t,t ] := b B c [t,t min 1, tx T s(tx) ] b, s max #B c otherwise [t,t ] where s max is the maximum input size. So s c [t,t ] [0, 1] is the ratio of actual block size to maximum block size in time interval [t, t ]. Note that we are taking the minimum, because it is sometimes possible for there to be more inputs than blocks. 3. Let δ, N, let m M, and let mf MF. Then we define a modified minimum fees function mf δ,m MF by ( ) mf δ,m (c, tx) := m s c [i(tx) δ,i(tx) ] mf(c, tx). This means that the block size ratio of a sliding time window of δ slots is used to modify the underlying fees function, increasing fees when that ratio was high. The more complicated minimum fees functions defined in definition 5.7 add a dynamic aspect to fee calculation, allowing fees to dynamically adapt to fluctuating block sizes. 5.3 Node Policies From now on, let us fix a sufficiently large 0 and a minimum fees function mf MF. By definition 5.2 and theorem 5.4, we get induced local functions { mf n : T (0, ) } n N, which agree on any given transaction with very high probability. Definition 5.8. For a node n N, let T n valid := { tx T f(tx) mf n (tx) } be the subset of valid transactions, i.e. the subset of those transactions whose included fee is at least as high as the minimum fee given by mf n. We call a transaction tx n-valid iff tx T n valid. Remark 5.9. Note that theorem 5.4 implies that for n, n N and tx T, transaction tx is n-valid if and only if it is n -valid with high probability. We are now ready to formulate our first policy, which all nodes should enforce: 8

9 Policy Honest nodes n should only accept and relay n-valid transactions, and they should only accept blocks in which all transactions are n-valid. This policy will (hopefully) prevent DDoS attacks by ensuring that transactions with insufficient fees will not be included in mempools, will not be relayed to other nodes and will not be written into the blockchain. Remark Note, however, that policy 5.10 may not be enough to prevent mempools from growing too fast. To prevent transactions from being trapped in the mempools for a long time without ever being incorporated into a block, we should consider an additional policy of removing a transaction from the mempools when it is older than a given number of slots. To address our second reason for introducing transaction fees, namely giving incentives to input endorsers, we pick a maximum input size and additionally propose the following policy: Policy When building an (endorsed) input, node n should choose the input amongst the set of all valid inputs which maximizes the sum of transaction fees contained in the input, while keeping the sum of transaction sizes below the maximum input size. Note that a valid input in policy 5.12 is in particular valid in the sense of policy 5.10, i.e. all contained transactions will contain at least the minimum fees. Remark Policy 5.12 is only a first approximation to maximizing a slotleader s and input endorser s profit, because it considers only the transaction fees they gain, but ignores the costs (which are incurred by costs for resources like memory and CPU time). Therefore, instead of choosing the input that maximizes transaction fees, it would be more accurate to instead maximize the difference between transaction fees and costs. If at some later time, we will develop a good model for the costs associated with a transaction, we will be able to take those costs into account and refine the policy accordingly. Remark It may be computationally impractical to efficiently calculate the maximum in policy Instead, a node n can try to approximate that maximum, for example using the following greedy heuristic. Algorithm Let n be a node and M n s mempool, containing only n- valid transactions (by policy 5.10). Then an input B, which approximates the maximum-fee input from policy 5.12, can be constructed as follows: I {} loop C {tx M tx could be added to I} if C = {} then return I else 9

10 c arg max tx C I I {c} M M \ {c} end if end loop f(tx) s(tx) Remark Note that we cannot simply sort all transactions in the mempool by descending order of fees per size ratio and then keep adding transactions to the input until we reach the maximum input size, because there may be precursor relations between inputs in the mempool, i.e. transactions that use the output of another transaction in the mempool as transaction input. 5.4 Fee Distribution Now that we have determined ways to calculate minimum fees for transactions and policies regarding relay of transactions and building endorsed inputs, it remains to clarify how to actually distribute fees amongst stakeholders. We propose to follow the method described in [3, 7]: Let c C be the blockchain, and consider an epoch [t, t := t + d 1] N with slot leaders L 1,..., L d, blocks B := B c [t,t ], endorsed inputs I := b B Ib, input endorsers E 1,..., E r who contributed at least one input from I and total fees F := b B tx T f(tx). b Then each stakeholder U can claim ( { } # j {1... r} U = E j + #{ j {1... d} }) U = L j F. (5.3) 2r 2d. Note that at a later point, (5.3) can be replaced by a more sophisticated distribution scheme which for example rewards input endorsers for endorsing more valuable transactions, which punishes slot leaders that did not actually create a block, or which rewards other stakeholders like the participants in the coin-tossing protocol as well. We must however be careful to ensure that [3, Proposition 7.1] still holds, at least if we do not want to give up the game-theoretic guarantees provided by that proposition. 10

11 6 Haskell Implementation In this section, we want to look at a simple Haskell implementation of the ideas discussed in section 5. It favours simplicity over efficiency. We define some type synonyms... type Size = Int type Complexity = Double type Ada = Int type Slot = Int... and a simple typeclass for things that know in which slot they have been created : class HasSlot a where slot :: a Slot Now we define a type class BCS a for an abstract blockchain system. For the time being, this will just contain the methods that we need to write down the algorithms from section 5. An instance of the class will have three associated types, Tx a for transactions, Input a for endorsed inputs and Block a for blocks. class (HasSlot (Tx a), HasSlot (Input a), HasSlot (Block a), Eq (Tx a), Eq (Input a), Eq (Block a) ) BCS a where data Tx a :: data Input a :: data Block a :: previousblock :: Block a Maybe (Block a) genesis :: Block a emptyinput :: Slot Input a transactionsi :: Input a [Tx a ] transactionsb :: Block a [Tx a ] inputs :: Block a [input a ] wellformed :: Tx a Bool size :: Tx a Size fees :: Tx a Ada complexity :: Tx a Complexity tryadd :: Input a Tx a Maybe (Input a) 11

12 Function previousblock returns Just the block previous to this one in the blockchain (or Nothing in the case of the genesis block), emptyinput creates an empty input in the specified slot, transactionsi gives the transactions contained in an input, transactionsb gives those contained in a block (see 5.1(11)), inputs gives the inputs contained in a block, wellformed checks whether a transaction is well-formed (has the required signatures etc.), and tryadd tries to add the transaction to the input and returns Just the resulting input or Nothing if the transaction can not be added (for example because of insufficient input or because the resulting input size would be too large). We define type synonyms for mempools and blockchains: type Mempool a = [Tx a ] type Chain a = Block a In our implementation, a (block-)chain has the same datatype as a block, where the chain given by a block is simply the path from the block back to the genesis block (using previousblock). We can easily define function c B c from definition 5.1(3), which gives the blocks contained in a chain: blocks :: BCS a Chain a [Block a ] blocks c = case previousblock c of Nothing [c ] Just c c : blocks c And for a chain c and slots t and t, we can compute B c [t,t ] from definition 5.1(4): blocksslots :: BCS a Chain a Slot Slot [Block a ] blocksslots chain t t = filter intime $ blocks chain where intime block = let i = slot block in t i i t Now that these preliminary definitions are out of the way, we can start implementing some of the things we discussed in section 5. Let us start with the restriction function c c t from definition 5.1(7): restrictchain :: BCS a Slot Chain a Chain a restrictchain s c c genesis slot c s = c otherwise = restrictchain s $ fromjust $ previousblock c We define the type MF of minimum fees functions from definition 5.2 that look at the blockchain blocks in the past (note that is not visible in the type). We also define the corresponding function mf n from (5.1), which takes such a minimal fees function,, the current blockchain and a transaction and returns the minimal fees for that transaction: 12

13 type MF a = Chain a Tx a Ada mfn :: BCS a MF a Slot Chain a Tx a Ada mfn f delta chain tx = f (restrictchain (slot tx delta) chain) tx For a minimum price per byte m, we can also define the simple function mf m MF from definition 5.6: mfm :: BCS a Ada MF a mfm m = (m ) size Let us now turn to the dynamic fee functions from definition 5.7! type M = Double Double ratio :: BCS a Size Chain a Slot Slot Double ratio maxsize chain t t = case blocksslots chain t t of [ ] 1 bs min 1 $ fromintegral (sum [size tx b bs, tx transactionsb b ])/ fromintegral (maxsize length bs) dynamic :: BCS a Size M Slot Slot MF a MF a dynamic maxsize m del delta mf chain tx = let t = slot tx delta t = t del in round $ m (ratio maxsize chain t t ) fromintegral (mf chain tx) Type M is used for functions from M (definition 5.7(1)), ratio calculates the ratio s c [t,t ] from definition 5.7(2), and dynamic gives us the dynamic modification mf δ,m from definition 5.7(3). The validity of a transaction from the point of view of a node (see definition 5.8) is determined by the following Haskell predicate: isvalidtx :: BCS a MF a Slot Chain a Tx a Bool isvalidtx f delta chain tx = wellformed tx fees tx mfn f delta chain tx Function isvalid allows us to implement policy For policy 5.12, we can now implement algorithm 5.15 in Haskell: createinput :: forall a BCS a Slot Mempool a Input a createinput sl = go (emptyinput sl) where go :: Input a [Tx a ] Input a go input pool = case candidates input pool of [ ] input 13

14 cs let c = maximumby (comparing feesperbyte) cs cs = filter ( c) cs in go (fromjust $ tryadd input c) cs candidates :: Input a [Tx a ] [Tx a ] candidates b = filter (isjust tryadd b) feesperbyte :: Tx a Double feesperbyte tx = fromintegral (fees tx) / fromintegral (size tx) Function createinput takes the current slot and the mempool as input and creates an approximately optimal input. 7 Open Questions How do we pragmatically start with this? We probably do not need premium fees and refunds at first, but we definitely do need minimum fees and an explicit finite transaction lifetime. How simple can the formular for the calculation of minimum fees be? Are minimum fees that are proportional to the transaction size enough for the first iteration? What is the incentive for nodes, which are not slot leaders, to actually give better service to transactions with high fees? (For that matter, what is the incentive for such nodes to follow the protocol anyway?) Does the theorem about the approximate Nash equilibrium [3, Proposition 7.1] still hold in the presence of premium fees and refunds? (It should, because refunds can just be looked at as resulting in a smaller pool, so the proof should still work.) How to prevent transaction submitters from lieing about the issue date? If a node sees a transaction with transaction date in the future, it can drop the transaction, but if it sees a transaction with a past date, it does not know for how long the transaction has really been in the system... References [1] Bitcoin Transaction fees. fees. Accessed: [2] Ethereum Classic Account Types, Gas, and Transactions. contracts-and-transactions/account-types-gas-and-transactions. html. Accessed:

15 [3] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. Ouroboros: A provably secure proof-of-stake blockchain protocol. Cryptology eprint Archive, Report 2016/889, /889. [4] Litecoin Transaction fees. Accessed: [5] How much are Monero transactions? monero-transaction-fees. Accessed: [6] NEM a Pol cryptocurrency. Accessed: [7] Ripple Transaction Cost. transaction-cost/. Accessed: