Funding Systems: Part 1 — Resource Allocation
The Provenance Blockchain network is a public, open source, and decentralized proof of stake blockchain. The key to a sustainable network is a solid funding system architecture that is well aligned with the value provided for the services offered. This article is the first in a series that breaks down the theory, implementation, and governance of the fee systems within the Provenance Blockchain.
Background
The Provenance Blockchain has a unique and expressive funding system based on transaction fees and incentive. This system allows the cost of running the network to be distributed not only based on the resources required for each transaction but also according to the value the service provides. The design criteria used in creating the funding system were supporting low cost transactions while also encouraging the growth of high value transactions. The funding system starts with understanding the resources available in the network and how they can be allocated.
Resources
The Provenance Blockchain has a finite amount of processing power and resources available for use when computing each block given the need for a consistent block time interval. This capacity varies based on the distribution of nodes, network latency, and computing hardware used. Based on extensive testing, a resource capacity limit was established for the network. For each second a conservative value of 10,000,000 units was derived. Each unit represents data read from the chain, written to disk, and cpu time. In blockchain terms these units are known as “gas”. With a block interval of 6 seconds this means that each block has a limit of 60 million units available. It is important to understand the capacity of the network because it allows us to define a limit on the amount of work we attempt ensuring consistent block times — an important factor for ensuring timely and consistent transaction finality. The limit of 60 million gas per block has been fixed in the consensus parameters for the blockchain. Over time as the network composition changes, this limit may need to be revised to ensure the intended block interval is maintained.
A properly calibrated transaction will require a gas value that matches the number of the transactions that can fit into the block without slowing down the network. If the gas amount assigned to a transaction is too low then the network will be overloaded when blocks are completely filled with these transactions as more resources are actually required than the limits established. Conversely if a transaction consumes more gas than the resources it actually consumes, it will waste the capacity in each block which could be used for other transactions. This is why cost recovery of transactions cannot be achieved through manipulating gas costs alone.
Capacity and Commit Times
The blockchain consistently cuts blocks regardless of the transactions submitted. These consistently cut blocks prove the availability and reliability of the network. Even a block with no transactions still records important network tasks such the next validator to propose a block, and monitoring the uptime of each validator through their votes. In an ideal case, each block would be completely full of transactions with no more than the network can handle. Full blocks represent the most efficient use of the network resources. Unfortunately, if a network has completely full blocks this can result in transactions waiting for an open slot. With a typical variability in demand, a transaction might need to wait a block or two before a slot opens. When the network is in this state it will accept the most valuable transactions first (those that are offering the highest fees) leaving the lower value transactions to wait until the network has free resources to respond. This pay-for-priority aspect is fundamental to the health of the blockchain by managing its growth in a sustainable and fully self-funded way. Ultimately a global blockchain network is expensive to run and given its fixed capacity, these resources must be allocated primarily to tasks that do the best job funding the network.
Pricing Transaction Resources
A transaction must cost at least as much as the resources it requires to process. This is why the first component of a transaction fee is the payment for the resources in gas required to record it. A user submits a large enough fee to cover the gas required to record their transaction. The network will enforce this by asserting that the gas amount the user claims the transaction will require is not exceeded. If this occurs the network will stop processing the transaction, but it will still take the fee provided to cover the amount of work performed by all of the network validators. For this reason the user will want to ensure they have assigned enough gas to their transaction such that the validators will be able to successfully record it with the resources allotted.
The user decides how much to pay for each unit of gas. Based on their chosen rate they multiply against the gas amount to determine the amount their transaction fee should be. The rate the user selects can be no lower than the network wide floor price for gas or it will be immediately rejected. In addition, each validator can set their own threshold for the value a transaction must pay before they will process the transaction. Each validator that raises their threshold above the minimum is one less validator proposing blocks that can commit the transaction. This will effectively raise the gas price floor a user must pay or their transaction will have to wait for a validator to accept it.
When the network is running at full capacity there is an additional incentive for each user to pay a higher rate for their gas resources. If everyone is trying to use the same or similar types of transactions then they will all have roughly the same amount of gas required. Offering a higher rate for the gas used will result in their transaction moving towards the front of the queue for a given block while also having a higher chance of exceeding the minimum price acceptable for all of the validators.
This same pricing dynamic encourages a user to not overestimate the amount of gas their transaction will use since this will result in a lower rate per unit given the same fee and ultimately a lower value transaction. Overestimating the amount of gas a transaction will require reduces the amount of gas allocation in a given block for everyone else. In order to ensure that a user does not submit extremely large transaction that crowd out everyone else regardless of price, the network enforces a hard limit on the maximum amount of gas any one transaction can consume (4 million gas).
Pricing Transaction Value
In addition to the simple pricing of resources used for each transaction, the network can only grow by offering additional value that users will pay for. This is because while the size of the network can grow, the fundamental way a blockchain block is computed is using a single machine. This means there is a hard limit on the amount of resources that will ever be available on a single blockchain. As there is a fixed amount of resource the only way to grow the network further is through capturing a portion of the value the network provides.
For certain transactions such as creating a new token, adding a loan, or recording a specific attribute against an address, there is additional business value beyond the basic transactions such as moving tokens between accounts. For these types of transactions a user must pay a value fee in addition to the resources they use. This value fee results in a transaction price that is immediately higher than transactions without these fees. With a higher fee the transaction will immediately move towards the front of any transaction queue and be recorded before all the lower value transactions. This dynamic is an important part in shaping the growth of transaction volume towards fewer high value transactions that align well with the ways a blockchain functions.
Scaling For Volume
Certain types of applications, such as payments, involve a high number of small, low cost transactions. Given the incentives outlined above, it might seems like these would be incompatible with the Provenance Blockchain. This is not the case, however, since the Provenance Blockchain has been designed from the start to be a network that links more than one chain together. When a payment system is added to the network, it may start out small, which is a good fit for the excess capacity in the primary blockchain. As the needs of the payment application grow there will come a point where the available network capacity is insufficient. As this point is reach a child zone network can be created that is secured by the primary core network. This child zone can have unique tuning parameters and its own set of resources specifically chosen to align with the needs of the application. The child zone is able to communicate with the primary Provenance Blockchain to share accounts, transfer tokens, and more. Further, the APIs between the child zone and the primary network are exactly the same, meaning that the higher level user applications can seamlessly transition over from the primary network without code changes.
Scaling With Client Data Processing
From the start it was clear that certain types of financial information would consume far too many network resources if they were recorded directly on the blockchain. Further, certain types of financial information is not suitable for recording in a public ledger. For these applications the Provenance Blockchain includes the concept of a Client Execution Environment which allows for off-chain processing and data to still have a detailed summary of proof recorded on-chain. These proofs are significantly small than the source data, often a few bytes of data hashes derived from off-chain records that are hundreds of megabytes in size. The beauty of this system is that anyone who the user shares their data with can verify the data they received agains the proofs on-chain such that they do not need to trust the sending user, they can rely on the blockchain truths that have been established. The Client Execution Environment has become a central feature that defines how the Provenance Blockchain records financial assets such as mortgages, equity lines of credit, and more directly to the chain in an efficient way. Further, the extra value that this system provides is an opportunity for a value-based fee that allows the network to grow.
Future Value Growth
The growth, and ultimately the success, of the Provenance Blockchain is dependent on developers bringing new use cases that drive value to the network. These new use cases can be built on the existing protocol capabilities, or they can use “smart contracts” — code loaded directly into the blockchain, to extend the protocol. Smart contracts present an exciting opportunity for developers to add new features that are perfectly tailored for specific business cases. These new contracts can drive tremendous value for financial institutions through cost savings. Developers are able to define measures for the value these new features provide and earn fees from this value directly when the contract is used.
An example of one such smart contract might be a bilateral settlement asset exchange. In the traditional finance world such transactions are common and typically incur a small percentage fee based on the value being exchanged. For a 100 million dollar settlement, even a small fee rate has significant value. The developers of this blockchain-based solution have the opportunity to propose a lower fee as a cost savings to drive interest in their application. These fees get split 50:50 between the network and the developer themselves. As a suggested split, if the traditional finance world fee was 90 bps, then the recommended fee structure would be 60 bps where the transaction costs are one third lower than the traditional market, the developer takes one third of the value, and the network is ascribed the remaining third.
Summary
This introduction into the architecture of the blockchain funding system has covered a significant amount of ground starting with the definition of the resources in play, the amount of resources available, pricing the resource, and balancing competition when the system is at full capacity. We continued through how to grow the capacity of the network with unique new applications and how the existing uses can be optimized to make the most of the available resources. Most importantly we have covered how the use of value-based fees are the key to the success of the network and its future growth.
In part two of this funding system series I will describe in detail how the Provenance Blockchain realizes these capabilities as a collection of fee modules, both deployed as well as those in development. The fee modules form the heart of how fees flow from transactions back to the network participants that run the machines powering the network itself. Theses modules also represent the tools that allow revenue streams to be directed that can reward specific beneficial actions for the network such as not only the traditional staking for security, but also actively voting on proposals, delegating across a range of validators outside the top ten, and more.
The third and final part of this series will explore the controls that the governance system has over all of these capabilities to set specific thresholds for fees, resource allocations, incentive programs, and more.
IRA MILLER
Ira is a software engineer from Montana working on the Provenance blockchain protocol. Before joining Figure he worked for the Stanford Research Institute focusing on distributed systems. He believes blockchain’s ability to transform trust into truth will have a transformative impact on the financial services industry. Outside of work he enjoys a good espresso, cycling, and traveling.
