The Future of Fintech: Part 2
Part 1 can be found here if not read.
The Future of Payments
Public blockchains merge the rail layer into the vault layer, significantly simplifying the current complexity of payment networks. Current debit/credit transactions typically require four middlemen: the payment processor, the issuing bank, the payment network, and acquiring the bank (along with nine steps of interactions between these parties). International bank wires typically require four as well: the sender’s bank, the receiver’s bank, and two correspondent banks (along with four steps of interactions between these parties). Blockchains reduce the intermediaries in modern payment rails from approximately four to one, the chain itself. In turn, this reduces payment processes that previously took four to nine steps down to two: the payer signs the transaction and the blockchain executes the transaction.
However, public blockchains are not currently adequate for all types of payments. There are three properties of a sufficient payment scheme: scalability, privacy, and security. Blockchain-based payments are currently unable to fully optimize these three variables simultaneously, although they will be able to in the near future, using a combination of layer-one and layer-two solutions.
Scalability can be measured via two components: clearing/settlement speed and transaction throughput. Today, blockchains can clear and settle payments significantly faster than legacy rails. However, blockchains’ transaction throughput is currently limited by two parameters that blockchains optimize for security rather than scalability: block space and block time.
- As block space decreases, blockchains become more decentralized (more nodes can validate the chain), which increases a blockchains’ security. However, smaller block spaces limit how many transactions can be processed in one block.
- As block time increases, validators have more time to verify the correct state of the chain (more time allows for more communication among nodes), which increases a blockchains’ security. However, extended block times limit how frequently blocks (and therefore transactions) can be processed.
Consequently, blockchains’ throughput is currently inadequate for most payment use cases: blockchains can process ~15 tx/sec at a fee of ~$0.11 per transaction. At times of high demand to transact, fees can increase by an order of magnitude (up to $5.00), while tx/sec remains constant. These transactions are not even private: they publicize pseudo-anonymous information, such as users’ public key addresses, as well as how much money was sent. Pseudo-anonymous checking accounts are unacceptable for most corporations and individuals, as they would enable competitors/peers to monitor essential operations of their businesses/lives.
Private transactions are possible, but require more complexity and thus consume a larger portion of block space than regular transactions: the result is that blockchains can only process approximately two private tx/sec currently, which means that blockchains could not even handle the full demand of American bi-directional international wires today (Although, even at this speed, blockchains still present an alternative solution to a market previously monopolized by banks.).
In order to make blockchains more scalable for both inter-bank wires and everyday transactions (a use case that blockchains will eventually serve), developers are in the process of deploying competing horizontal scaling schemes: both layer-two solutions and sharding. Both layer-two solutions and sharding maintain similar block times and block sizes as today’s standards, but still increase throughput drastically by adding more nodes to the network and dividing the tasks of processing transactions between distinct subsets of nodes.
Layer-Two: A Brief Overview
The horizontal scaling provided by layer-two’s will enable public blockchains to process pseudo-anonymous transactions on par with current rails’ capabilities and private transactions more efficient than current rails’ international capabilities, while maintaining fees that are still orders of magnitude lower. Within two years, layer-two solutions will be able to process fully private transactions within the same realm as current rails’ capabilities, so long as innovation in the zero-knowledge proof space continues to improve at rate of at least 2x (in terms of both generation time and compactness of the proof). Additionally, if layer-one solutions successfully implement sharding, the combination of layer-twos on top of sharded layer-ones will allow for an order of magnitude improvement (or two) over today’s current system in both speed, fees, and privacy (within two years).
There are two leading layer-two solutions: zk rollups and optimistic rollups. These two solutions share the same leading design principle: a decentralized community of nodes executes transactions outside of the layer-one blockchain, expanding block space ‘out-of-protocol’, but posts enough data to the layer-one chain such that layer-one can verify the correctness of the transactions (either through fraud proofs or validity proofs). This approach leverages the best feature of layer-one chains, security (which is often measured in terms of decentralization, and layer-one chains are inherently more decentralized than layer-twos), while significantly enhancing scalability.
It requires an additional step to move funds between layer-one and layer-two chains, similar to how funds are moved between checkings and savings accounts in traditional banking. However, once funds reside in a layer-two solution, it still only requires one middleman (now the layer-two chain) and two steps to execute a transaction.
Sharding: A Brief Overview
Sharding is very similar in design to layer-twos: both horizontally scale blockchains, relying on an increase of validators rather than an increase in the size required to run validators; both are a set of individual blockchains that use a base chain to shuffle their validator sets and verify the correctness of their state. Layer-two solutions can be termed as ‘free market’ versions of sharding due to their implementation as smart contracts on their corresponding layer-one chains: no developer or validator is forced to use or validate a layer-two solution; they must explicitly choose to, whereas developers and validators will be forced to adopt to a sharding environment should one be implemented.
Sharding expands the blockspace of a blockchain ‘in-protocol’ by transitioning a blockchain of block size X into many ‘sub-blockchains’ of block size X (In the case of Ethereum, 64 blockchains of block size 128kB), with all of these blockchains secured by one larger, shared blockchain. Each of these ‘sub-blockchains’ are called shards, while the shared blockchain that secures every shard is called a ‘relay chain’ (also referred to as a ‘beacon chain.’).
Relay chains use crosslinks to confirm shard blocks, so that specified shard blocks can become finalized in the relay chain. Shard chains use hash pointers to reference relay blocks, so that shard chains can securely execute cross-shard transactions. The innovations required to make sharding work are centered around stateless clients, erasure coding, and secure networking.
There still exists doubt about whether sharding will work efficiently enough to achieve mainstream adoption, as no sharding scheme has yet to be successfully implemented. However, blockchains do not need in-protocol sharding to rival today’s payments rails: layer-two solutions act as free-market versions of sharding, are coming to market now, and will be sufficient to scale blockchains to meet the capabilities of today’s payment rails. While layer-two solutions currently exist on top of layer-one chains, if sharding is successful, layer-twos will exist on top of shards, which will exist on top of a relay chain.
Layer-ones can currently generate ~2 private tx/sec through on-chain mixers. Mixer technology is still nascent, but numerous beta versions are live on public blockchains, one of which is under development by Ernst & Young, one of the largest global accounting firms.
While layer-two solutions have not implemented mixers yet, optimistic rollups promise to do so this year, as optimistic rollups are able to support the same level of computation as their correspondent layer-one chains. Initially, mixers on optimistic rollups may only increase public blockchains’ private transaction throughput less than an order of magnitude over today’s private throughput of ~2 private tx/sec (We estimate ~10 private tx/sec.). However, optimistic rollups designed specifically for the execution of mixers should eventually be able to support ~200 private tx/sec, assuming no enhancement in mixer efficiency.
However, mixer efficiently will likely continue to improve at a rate of at least 2x per year due to increasing innovation in the zero-knowledge proof space, driving private throughput to within an order of magnitude of today’s systems (and with faster clearing/settlement times). Sharding, if successful, would increase the throughput of optimistic-rollup-based private transactions by two more orders of magnitude (over 10,000 private tx/sec, assuming no improvement in mixer efficiency).
As the use of mixers proliferates across blockchains, user privacy will be significantly stronger than today’s standards: mixer transactions return access control of user data to the user herself; vaults and rails can no longer sell user payment data unless the user specifically gives them access.
Zk rollups will take longer to implement private transactions. In order to achieve privacy, zk rollups must implement recursive zero-knowledge proofs, which, despite the accelerating rate of innovation in the zero-knowledge proof space, is likely multiple years away from being possible. Once recursive zero-knowledge proofs are efficient enough (in terms of proof generation and proof size) to be deployed, zk rollups will be able to scale to the same, if not significantly higher, levels of private throughput of optimistic rollups. Until then, however, zk rollups can provide little to no privacy guarantees at all.
The security of blockchains can be analyzed via two sub-factors: the security of the chain itself (as well as its parts, such as layer-twos) and the security that, even if the chain operates correctly, users are not liable to the consequences of a fraudulent transaction.
Factor One: The Security of the Chain Itself
The security of blockchains rely on both technical security and social security. Technical security is achieved through three disciplines: cryptography, economics, and computer science. Cryptography ensures the validity of all transactions: users send transactions using cryptography; nodes package and verify blocks using cryptography. However, altruism is ineffective in ensuring that every node applies cryptography correctly. Thus, blockchains implement economic incentives to ensure that a decentralized community of actors append blocks to the chain that only contain valid transactions: validators receive block rewards for honest behavior and slashing penalties (directly or indirectly, depending on the consensus algorithm used) for dishonest behavior. All of a blockchain’s cryptographic and economic features are enforced through code, computer science, run by nodes of that blockchain.
Social security entails the ability for honest users to reconvene even in the event of a ‘successful’ technical attack. In the past (when proof-of-work was the most widespread consensus algorithm), social security relies on shared beliefs, namely that code is not law (as exhibited by the Ethereum hard fork in 2016), and the ability to communicate via online channels (Reddit, Discord, Twitter, etc). Because of social security, blockchains have run securely even if the face of attacks, with honest actors all agreeing to move to the ‘honest’ chain.
Chains secured by certain consensus algorithms, such as proof-of-stake, can now encode social security (thus morphing it into technical security): honest actors can continue to validate a minority chain by slashing and redistributing that attacker’s stake on the minority chain among the honest participants. This significantly increases the security of blockchains, making them almost unattackable by even the wealthiest, most malicious actors.
Other consensus algorithms, such as proof-of-work, do not provide the same ability to technically reconvene on the minority chain, and so they rely on greater community participation on online forums to arrive socially on the correct chain. This is less secure, as un-encoded social security can lead to significantly more variation than encoded social security, hence why proof-of-stake appears to be the dominant consensus algorithm moving forward.
As for layer-two solutions, optimistic rollups act as another blockchain on top of the layer-one blockchain and thus follow similar properties (although there are some differences, specifically with regards to how to merge technical and social security), while zk rollups are an exception to using economics for security.
Zk rollups garner their security properties from validity proofs, which leverage cryptography alone to prove correctness. This feature prevents zk rollup validators from posting invalid transactions, which in turn allows for users to exit from a zk rollup back to its correspondent layer-one in the layer-one’s next block (~13 seconds in Ethereum’s case). Some zk rollup teams have implemented economic incentives to enhance zk rollups’ scalability. Economic incentives in zk rollups allow for sub-second, guaranteed transactions (at the scale of 2000 tx/second). However, there is a strong difference between enhancement via incentives to perform optimally and a reliance on incentives to perform securely, as in the case of optimistic rollups.
Optimistic rollups rely on two blockchains for security: the rollup and its corresponding layer-one. To provide adequate security assurances through economic incentives, optimistic rollups implement challenge periods (via their smart contracts on layer-ones), where validators can challenge an optimistic block by locking funds in a smart contract. Challenges reward honest actors and punish bad actors (through distributing either the block proposer’s stake or the challenger’s stake to the honest party, similarly to layer-one proof-of-stake chains ‘in-protocol’).
The implementation of challenge periods increases user exit times from optimistic rollups back to layer-one chains significantly: several hours (lower bound) to one week (upper bound). Sufficient challenge period length is extremely important for security of optimistic rollups. Proof-of-stake optimistic rollups cannot rely on the same social securities as proof-of-stake layer-ones, as, if an attacker successfully compromises and exits an optimistic rollup, the layer-one will not recognize it as an attack. Long challenge periods mitigate this risk, as they allow honest validators to have enough time to find and confirm dishonest behavior.
Proponents of optimistic rollups have developed workarounds for their suboptimal exit times: to establish a credit market in which credit providers settle user exits to layer-ones for a fee. This credit market would have little implementation difficulty due to the advent of submarine swaps and the creditor’s ability to both monitor and verify the optimistic rollup’s state in real time, allowing the creditor to be confident that borrower’s layer-two funds would become their own should the creditor execute the swap. Credit markets decrease exit times of optimistic rollups from hours-days to minutes.
Thus, with the introduction of additional economic incentives on top of layer-one’s incentives, optimistic rollups can achieve scalability, privacy, and security in the near future. Consequently, optimistic rollups appear to be a better near-term solution for a disruptive blockchain-based payment system, while zk rollups appear to be a better long-term solution due to their decrease in dependencies on economic incentives, relying neither on fraud proofs or credit markets. However, in the defense of optimistic rollups, a reliance on economic incentives has not yet been a problem for layer-one chains.
Factor Two: Anti-Fraud Solutions
The other significant aspect of security remains the same regardless of which layer-one or layer-two solution is used to transact: public blockchain infrastructure must combat fraudulent payments.
Current payment networks often place the risk of fraud onto the merchant, reversing payments to a merchant who may have had no idea they were being frauded. From first principles, placing the risk of fraudulent payment onto the merchant, who already loses margins because of fees paid to payment networks, is a user behavior that only exists because of the monopolies afforded to current payment networks.
Payments cleared on blockchains are irreversible. Thus, blockchains allow for a more rational solution: the risk of fraudulent payments is passed to the party that authorized the payment, either the user themself or the user’s digital wallet, should the user enlist in the wallet’s insurance solution. Digital wallets may provide this insurance for ‘free’.
Users will have the ability to choose between the two. Those that choose to authorize their payments alone (hopefully using some form of two-factor authentication) will likely be technologically savvy users, while mainstream users will choose to work with digital wallets.
Security of Centralized versus Decentralized Systems
Any system, whether centralized or decentralized, is composed of multiple parts, and each system type is only as secure as its least secure part. Decentralized systems inherently account for this in their designs. They build resilience into each part, with each part treating every other part as adversarial. Thus, if a hacker successfully attacks a part of a decentralized system, the hacker can only compromise that singular piece of the system. As decentralized systems grow in their number of parts, the security of each part remains the same.
However, centralized systems only protect their perimeters: internal parts are allowed to communicate with each other without assuming that their corresponding part could be adversarial. As centralized systems grow in their number of parts, the size of their perimeters increases as well, and consequently so does the attack surface for a hacker. Thus, as centralized systems grow, the security of each part, as well as the system more broadly, decreases. Consequently, blockchains (properly designed decentralized systems, in general) have significantly stronger security guarantees than centralized systems.
Triggering the S-Curve
Blockchains will eventually deliver more scalable, more private, and more secure payments than today’s payment infrastructure, but it will take multiple years before these three features can be optimized simultaneously, as teams continue to innovate on horizontal scaling solutions and zero-knowledge proof efficiency.
There are numerous actors that stand to benefit from blockchain payments as they exist today and in the very near future: international businesses, migrant workers, and citizens living under oppressive regimes. The first two parties stand to achieve significant efficiency gains, both due to cheaper fees and faster settlement times. The last group may be willing to put up with blockchains’ present shortcomings if their alternative is losing a significant amount of wealth from inflation.
The Future of the APIs
As blockchain-based banking/payment solutions proliferate, the APIs of today’s financial stack will be rendered irrelevant. The open-source ethos dominating public blockchain infrastructure renders obsolete both categories of current fintech APIs (rail APIs and data APIs).
Rail APIs, such as Square’s and Stripe’s, are made insignificant due to the open-source nature of layer-one and layer-two solution payment solutions: the code necessary to use these networks is already published, free of charge.
Data APIs, such as Plaid’s, exploit a lack of interbank standards with regards to data access control. Blockchains change the data ownership structure entirely: users control access to their data, instead of commercial banks. As to how digital wallets access consumers’ blockchain-based data will depend on the privacy solution (or lack thereof) used by the consumer:
- If the user does not utilize any privacy solution, all of that user’s transaction history would be public via his or her public address(es) on a public blockchain. Thus, a digital wallet could query the entire blockchain for the user’s activity through either a free-market query protocol, such as the Graph or Infura, or its own internal system.
- If the user utilizes zero-knowledge proof based privacy solutions (such as on-chain mixers or a recursive zero-knowledge proofs), the user could store their encrypted transaction history on a decentralized storage protocol, such as Filecoin, and authorize access to digital wallets through a proxy re-encryption protocol, such as NuCypher.
These protocols (query, storage, proxy re-encryption, as well as any other blockchain-based protocol) allow for free markets of services, consequently preventing any party from monopolizing access: anyone who raises fees excessively will be undercut by a competitor with little friction, as the very nature of a protocol allows for near-frictionless interoperability between service providers.
It will be up to consumers to choose how they manage their financial data, but all of the back-end interaction between query protocols, re-encryption protocols, blockchains, and decentralized file systems will be completely abstracted from them by digital wallets. In the near-term, our new financial stack is the following (‘no arrows’ indicates a double arrow):
If sharding is successful, our new financial stack becomes the following:
There are three layers of fintech — the vault, the rails, and the APIs. Each of these layers will be disrupted by decentralized finance. While each of these three layers possess numerous moats, history serves as a reminder that all moats are temporary. For example, telecommunication companies also benefited from significant regulatory and network moats, and yet they could not do anything to prevent the advent of the internet. The largest open question that remains is whether layer-one chains will interface with traditional vaults (through stablecoin issuers’ DBSs), federal governments’ proprietary chains (through central banks’ CBDCs), or remain fully sovereign (through a decentralized communities’ FCOS). Blockchains leave little room for the incumbents of the payment and API layers, other than their becoming providers on top blockchain-based protocols (such as a validator of layer-two rollup or a ‘re-encryptor’ in a proxy re-encryption protocol).
However, the power of incumbents will not disappear suddenly or completely. There always exists a strong faction of users that are slow to adopt new technology, and incumbents will continue to serve these people. That said, efficiency wins overtime, as people will learn new behaviors to save money and time. Thus, risk management practices would suggest that these incumbents should bet on public blockchain infrastructure, in order to de-risk their overexposure to outdated technologies. The only way for them to do this, unfortunately for them, is to buy the assets that secure these public blockchains. Other than the assets that secure public blockchain infrastructure, digital wallets stand the most to gain.
Fintech is already converging inside digital wallets, such that payments, savings, budgeting, investments, and other financial services are all accessible in application. Digital wallets will benefit from the free-market economics that public blockchains provide below them: reduced fees at the infrastructure layers will allow digital wallets to produce their services at incredibly low costs. Additionally, digital wallets will be empowered to conduct further value-add services, such as abstracting away all of the complicated user behavior required to make blockchain-based finance work: custody solutions, anti-fraud solutions, and the managing of access to users’ private data. However, these front-ends will not benefit from moats in the same way that current banks have, as the barrier to enter the digital wallet space will be significantly lower than it is today, another advent of public blockchain infrastructure.
The full article can be found here. Special thanks to March Zheng, Michael Stalder, Gary Thung, Maximillian Jungreis, and Ankit Goyal for their feedback.