This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at Stellar and the challenge it could pose to today’s dominant platform, Ethereum.

In a crypto winter that has seen Ripple take over Ethereum’s long held number two ranking market cap, Ripple’s offspring, Stellar, has quietly risen into the top ten. Despite its beginnings as a Ripple-like consortium chain, Stellar has evolved into an open, decentralized platform that supports smart contracts.

 

Stellar’s co-founder Jeb McCaleb has a long history of creating globally dominant systems in the decentralized space. In 2000, eight years before Bitcoin was a glimmer in Satoshi’s eye, McCaleb and Sam Yagan created the eDonkey peer-to-peer file sharing network, which in 2004 became the most widely used file sharing network on the Internet until it was overtaken by Bittorrent in 2007.

In 2007 McCaleb’s brief interest in creating a trading site for Magic: The Gathering cards, led him to create the Magic: The Gathering Online Exchange (Mt. Gox). In July 2010, wanting “a good way to buy and sell Bitcoins,” he turned Mt. Gox into a bitcoin exchange that would eventually become the world’s largest, handling over 70 percent of all Bitcoin transactions at its peak.

Image from Meiklejohn et al., 2013

 

In February 2011 McCaleb sold the Mt. Gox exchange to Mark Karpelès. While Karpelès was CEO of Mt. Gox 850k bitcoins were stolen from the exchange’s wallets, fueling a downward spiral that ultimately led to the company’s bankruptcy in February 2014 and the arrest of Karpelès on charges of fraud and embezzlement in August 2015.

While Mt. Gox was imploding, McCaleb and Chris Larsen co-founded Opencoin to create a new digital currency based on the Ripplepay protocol developed by Ryan Fugger in 2004. McCaleb and team worked to evolve Ripplepay toward a more decentralized system based upon a web of trust among nodes, a concept foundational to Stellar. McCaleb remained with OpenCoin until July 2013 when he left over personal conflict with Larsen and perhaps other issues. A couple of months later OpenCoin officially became Ripple Labs Inc. and fully open sourced its code. It also launched the XRP coin, which is now the second largest cryptocurrency by market cap (McCaleb owns billions of XRP).

In February 2014, McCaleb announced he was working on a secret bitcoin project. The project was revealed as Stellar in July 2014 with the creation of the non-profit Stellar Development Foundation (SDF). SDF’s stated mission is “to promote global financial access, literacy, and inclusion […] through the development and maintenance of technology and partnerships.” Fueled with seed funding from Stripe and other investors SDF launched the Stellar network and the Lumens (XLM) token in July 2014.

 

On December 2, 2014 Stellar’s consensus protocol experienced a ledger fork that rolled back of hours of transactions. This prompted Stellar to temporarily centralize the network to a single node until it could launch a new provably safe, decentralized consensus protocol that was being designed by Stanford professor Dr. David Mazières. In April 2015, amid McCaleb’s legal battles with Ripple, the Stellar Consensus Protocol white paper was published.

The new consensus protocol went live in November 2015 and Stellar began building on it immediately, forming partnerships to facilitate cross-border payments that bridge crypto and fiat currencies. By the end of 2016 Stellar had announced several remittances and payments projects built on the Stellar network. In May, 2017 McCaleb and Brit Yonge co-founded the for-profit Lightyear to build a universal payment network on Stellar. Lightyear recently acquired Chain.com to form InterStellar, which is building tools, products, and services that make it easier to use and build on Stellar. In September 2017, Stellar announced the Stellar Partnership Grant Program, which would fund projects building on Stellar network and filling unmet needs of the Stellar ecosystem.

2018 has been a year of major ICOs on Stellar, starting with the Mobius’s 39 million USD raise in January and continuing with several other large token sales throughout the year. Whereas Ethereum is still far and away the leading platform for ICOs, concerns about Ethereum’s fees, security, scalability, and that of other issues have led some to consider Stellar a better alternative for issuing their token.

Stellar is not a typical smart contract platform in that it does not have a smart contract language or virtual machine that can be directly compared to Ethereum’s. Instead it provides a well-defined set of operations that it claims “can be used to build sophisticated smart contracts.” This is just one example of how Stellar’s approach is very different from Ethereum’s and other platforms we’ve looked at in this series. Other examples are that Stellar’s consensus protocol is not proof-of-anything, it has no mining or other sybil resistance mechanism, no one knows who all the nodes are, anyone can issue tokens for any real world asset and immediately trade them on the platform’s built-in exchange, and users can pay for goods and services in sheep even when the seller explicitly does not accept sheep.

It may be like comparing apples to sheep, but it will be interesting to see how Stellar’s novel approach to building an open smart contract platform compares to Ethereum’s. Let’s dive in.

Scalability

The Stellar network is often claimed to support thousands of transactions per second (TPS). The figure given on Stellar’s website is 1000 operations per second (OPS). The distinction between a Stellar transaction and a Stellar operation is important in understanding practical throughput limitations of Stellar and evaluating the various TPS claims that conflate the two.

Stellar transactions are used to send payments and execute state changes on the blockchain. They most closely resemble Ethereum transactions, having a source account, account sequence number, a list of operations to execute, digital signature(s), and some transaction fee specifications. The list of operations in a Stellar transaction is a sequence of state mutating actions that allow the transaction to create, pay, and manage accounts and perform other predefined functions. The operations in a Stellar transaction must be executed sequentially and atomically such that the failure of any operation will cause the whole transaction to fail reverting all state changes from prior operations. Thus Stellar operations most closely resemble state mutating Ethereum smart contract functions with revert failure semantics, where the sequence of function calls is determined by the execution path that the Ethereum transaction takes through the smart contract(s).

A ledger in Stellar is a collection of ordered transactions that the network reaches consensus on and chains together to create an immutable history, much like a block in Ethereum and other blockchains. Stellar has a protocol parameter limiting the number of transactions per ledger to 50 and a fixed limit of 100 operations per transaction. Since the network produces a new ledger containing up to 50 transactions and 5000 operations every 5 seconds on average, Stellar’s max capacity is 10 TPS and 1000 OPS.

However, that 1000 OPS is a theoretical maximum that can be orders of magnitude larger than what the network actually achieves in practice. A load test analysis conducted by the Kin Ecosystem Foundation set out to empirically determine the actual maximum TPS their application could achieve on Stellar. Expectations of high throughput, based on the common conflation of operations and transactions, were shattered when Kin discovered that their most common use case, which used 1 operation per transaction, achieved at most 10 operations per second using the network’s entire capacity. Kin assumed that this was a temporary problem that Stellar would fix and announced their decision to reissue their ERC20 token on Stellar, but shortly thereafter decided to build on their own fork of Stellar citing “business scale” issues with the original Stellar platform.

Image from Stellar Expert

A mix of different application types can significantly reduce the overall OPS the network realizes in practice. Data from Stellar’s mainnet, shown in the figure above, illustrates how the ratio of operations to transactions varies from ledger to ledger (each vertical bar is one ledger) and averages below 10-to-1 for a typical transaction mix. This results in an actual network-wide throughput that is nowhere near the theoretical maximum of 5000 operations per ledger (1000 OPS) even as the transaction count approaches the limit of 50 transactions per ledger (10 TPS).

The gross inefficiencies in achieving Stellar’s theoretical OPS limits arise from the fact that Stellar’s capacity is limited by transactions and not operations. If Stellar replaced the transactions per ledger limit with an operations per ledger limit then (with a limit of 5000 operations per ledger) it could actually achieve 1000 OPS and over 100 TPS under a typical transaction mix. This is essentially what Ethereum does with its block gas limit protocol parameter, which allows miners to fill each block with as many transactions as possible within the gas limit.

Currently, Ethereum’s Proof of Work (PoW) mining chain and Stellar’s Federated Byzantine Agreement System both realize on the order of 10 TPS in practice. Whereas Ethereum hopes to (someday) scale its base layer throughput 1000x with sharding (covered extensively in our last article), Stellar has, to date, provided few details on upcoming base layer scaling solutions. As recently as July, 2018 Jed McCaleb publicly stated that “At some point — to reach scalability — we will have to do things like sharding and subnetworks” but, at the time of writing, the only scaling solution that Stellar has publicly announced is the layer 2 payment channels project called Starlight.

Starlight works like other payment channel protocols such as Lightening Network and Raiden Network by locking up funds on-chain and allowing counterparties to make payments off-chain by exchanging signed messages, which are not broadcast to the network. Thus payments happen instantly, privately, and without fees. The counterparties can later close the channel cooperatively or force close if the other party misbehaves or goes silent. Like all layer 2 solutions, Starlight requires all parties (or their agents) to be online and monitoring the network while the channel is open so they can resolve any conflicts in a timely manner.

Starlight is currently an early demo deployed only on the testnet and only supports payments in the platform’s native XLM token. Support for non-native assets, routed payment channels, compatibility with other payment channel networks such as Lightening and Interledger, and deployment on the Stellar mainnet are in the Starlight roadmap for the coming year, but the delivery timelines are not specified.

The timeline for production ready layer 2 solutions on Ethereum is equally fuzzy. After years of development (and 33 million USD in ICO funding) Raiden recently announced deployment of an “alpha testing” release on the Ethereum mainnet, which is “not yet production ready.” Various flavors of Plasma have running testnet implementations and aspirations for Ethereum mainnet deployment in early 2019. Whereas Ethereum’s research and development resources are unparalleled among blockchains, they are spread out among a large number of layer 2 projects, none of which, at present, appears substantially more mature than Stellar’s Starlight project.

Although it’s currently unclear how Stellar plans to scale its base layer, we do know that it has at least one key advantage over Ethereum when it comes to implementing sharding: its federated byzantine agreement consensus protocol (described in the next section) provides instant finality (i.e. non-forking). Forks and chain reorganizations are naturally occurring phenomenons in blockchains like Ethereum. A transaction appearing in the latest block may be reverted or invalidated when the fork is resolved, which is why Ethereum users and applications must typically wait for several confirmations before considering a transaction to be final. A chain reorganization that reverts/invalidates some transactions on one shard will affect all dependent transactions on other shards and any transactions dependent on them, and so on, making cross-shard communication complicated and slow. Ethereum’s current approach to preventing this is to use checkpoints (blocks that cannot be reverted) as anchors for cross-shard communication, though the cost of achieving safety this way is a latency of several block times (on the order of minutes) for cross-shard interactions.

Unlike Ethereum, Stellar’s consensus protocol does not fork. Once the network reaches agreement on a ledger, the transactions in that ledger are final and can never be reverted. Having instant, not probabilistic, finality greatly simplifies and reduces the latency of cross-shard communication and even makes it possible to implement synchronous cross-shard transactions. It will be interesting to see what sort of sharding mechanism Stellar comes up with and how it compares to Ethereum’s in terms of throughput and latency.

Consensus Safety

The Stellar Consensus Protocol (SCP) is an interesting alternative to the Nakamoto Consensus style protocols implemented in Bitcoin, Ethereum, and several other blockchains. Both are designed to enable agreement on the order of transactions in a decentralized network where participation in consensus is open to anyone, including malicious actors.

To be viable a consensus protocol must simultaneously exhibit safety — agreement on the canonical sequence of valid transactions — and liveness — ability to continue sequencing transactions without getting permanently stuck. Both can be easily achieved on a centrally managed network, where the set of participating nodes is well known and it is reasonable to make assumptions about the eventual delivery of messages, but achieving this on an open, decentralized network with bad actors and unbounded delays is difficult. In fact, it’s theoretically impossible to achieve both safety and liveness with even one faulty node participating in the consensus process. Yet both Stellar and Ethereum seem to achieve safety and liveness in practice on the Internet while allowing open participation in consensus. Both platforms incorporate novel approaches to achieve this, though each has very different tradeoffs.

Ethereum employs Nakamoto Consensus, which utilizes cryptoeconomic mechanisms (e.g. mining, staking) to incentivize block production and keep the system live. Nakamoto Consensus favors liveness over safety, as it does not prevent forks, nor the double spends that forks enable. It is a common misconception that Nakamoto consensus “solves” the double spend problem. The solution lies not in the protocol, but in users and applications waiting an appropriate number of confirmations before accepting a payment as “final enough” to enact their end of the transaction. There is always some probability that a chain reorganization will cause the payment to be reverted (enabling a double spend) but the more confirmations that have accumulated, the lower that probability becomes. This scheme works well enough in practice, though it can take minutes or hours to gain enough assurance that a payment will not be double spent.

Stellar employs Federated Byzantine Agreement (FBA), which favors safety over liveness. An FBA protocol is essentially a Byzantine Fault Tolerant (BFT) protocol with an open participation model that allows consensus nodes to freely join and leave the network. Stellar’s FBA has been proven to be optimally safe in an asynchronous setting, meaning that it guarantees agreement under any failure scenario in which it’s possible for some protocol to provide such a guarantee. In contrast to Nakamoto consensus, SCP stalls when nodes cannot reach agreement, but, like most BFT protocols, the agreements it reaches are immediately final, so forks, chain reorganizations, and double spends are impossible (within some fault tolerance limits). However, unlike BFT protocols, SCP nodes cannot reach consensus by a fixed quorum (e.g. 2/3 of consensus nodes agreeing) because the set of nodes participating at any given time is unknown. Instead, they reach consensus through peer to peer trust arrangements managed locally at each node.

Much in the way Ethereum’s safety depends on the judicious use of confirmations, Stellar’s safety depends on prudent configuration of these trust arrangements. The provably optimal safety and “plausible” liveness properties of SCP only exist as long as the trust arrangements maintain a property called quorum intersection despite Byzantine failures. Otherwise the SCP network is as susceptible to safety failures as Ethereum is without confirmations.

What is quorum intersection despite Byzantine failures and how is it maintained? An SCP node defines its trust arrangements as a list of node sets, called quorum slices, that the node trusts to provide truthful information. The node will only agree to a ledger if all of the nodes in at least one of its quorum slices agrees to it. Nodes gossip their intentions to each other in a multi-stage federated voting process that reaches consensus once a quorum — a set of nodes that encompasses at least one quorum slice of each of its members — agrees on the same ledger. A network has quorum intersection if any two quorums we can construct overlap in at least one node (kind of like how actor relationships overlap with Kevin Bacon). With quorum intersection it’s not possible for two quorums to finalize different ledgers unless all of the overlapping nodes violate the protocol by voting for conflicting ledgers. If at least one of the overlapping nodes follows the protocol it will prevent conflicting ledgers from being finalized.

Image from David Mazières’s presentation on SCP (Dec 6, 2017)

The above slide illustrates a situation where Quorum A and Quorum B intersect at node V7. If V7 equivocates by telling all members of Quorum A it supports one ledger and telling all members of B it supports another conflicting ledger, then Quorum A and Quorum B can finalize those conflicting ledgers, violating all safety guarantees. This is where the “despite Byzantine failures” part of the property comes in; safety depends on the setup having quorum intersection after all the Byzantine nodes are removed.

If preserving quorum intersection despite Byzantine failures is so critical, and, as the SCP whitepaper states, each node is responsible for preserving it, then how should each node operator design their quorum slices to ensure this? Stellar advises picking “conservative slices that lead to large quorums” and Stellar’s blog recommends, “ensuring slices are large enough and that the nodes they contain are important enough not to risk their reputations by lying and feeding different information to different people.” Whereas larger quorum slices are more conservative with respect to safety (they increase the probability of maintaining quorum intersection), they do so at the expense of liveness (they are more likely to become blocked due to a single offline node). Stellar’s website offers some detailed guidance on choosing quorum slices and thresholds to balance liveness and safety, and even provides instructions for monitoring and repairing unhealthy quorum slices. However, these are just best practice recommendations, not an objective set of rules that a node administrator can follow to ensure quorum intersection despite Byzantine faults.

The consensus safety of the Stellar network hinges on the configuration choices of node operators, which are entirely subjective and loosely coordinated at best. However, Stellar points to the success of autonomously administered peering arrangements in inter-domain routing as an example of robust architecture emerging from market forces. However, as Greg Maxwell pointed out in a 2015 discussion with David Mazières, inter-domain routing is hardly a convincing precedent because routing systems can (and often must) work with inconsistencies, but ledgers require the strong safety properties of consensus systems.

Nonetheless, Mazières believes that an architecture that ensures safety through quorum intersection despite Byzantine faults will emerge from sets of pairing agreements. He envisions a specific architecture where quorum slices are configured to form a hierarchy with “anywhere from four to dozens of widely known and trusted financial institutions” residing at the top tier and individual “countries or geographic regions” in the middle tiers.

Image from David Mazières’s presentation on SCP (Dec 6, 2017)

In the figure above Mazières presents an example of how market forces could allow a de facto group of four top-tier banks to emerge from peering relationships. In this example, these banks only have trust relationships with each other, but the middle tier nodes include 2/4 top tier banks in each of their quorum slices (the presentation later shows how “paranoid” middle tier nodes could add non-profit nodes like Stellar, EFF, and ACLU to their quorum slices to act as watchdogs on colluding banks). Stellar is nudging node operators toward this architecture by providing syntax and examples that encourages structuring quorum slices in tiers and publishing a list of known validators with uptime stats on their website. These tools, along with the diligent monitoring and repair of quorum slices by node administrators, may be enough support to allow the Stellar network to maintain safety as Stellar grows and becomes more decentralized.

Like many blockchain projects, including Ethereum, Stellar is experimenting with adding some elements of centralization and trust to build a practically useful (vs theoretically pure) open, decentralized system. It’s not clear whether Stellar’s network can maintain consensus safety without these elements, but the mainnet has been running with open participation for 3 years without a major consensus failure.

Governance

Elements of centralization and trust are found in the current governance structures of both Ethereum and Stellar. The SDF, which oversees the distribution of the 100 billion XLM created at Stellar’s genesis, funds most of Stellar’s core development and selectively offers grants to certain projects building on Stellar. There are many autonomous Stellar-based projects, though some of the more prominent ones are run by McCaleb’s for-profit company Interstellar.

Similarly, the Ethereum Foundation, which controls the proceeds of the Ethereum crowdsale, funds much of Ethereum’s core development and selectively offers grants to certain projects building on Ethereum. There are a large number of other, autonomous projects building on Ethereum, over 50 of which are Consensys spokes, incubated by the for-profit Consensys Labs.

Stellar’s monetary policy and governance over its native currency is somewhat different than Ethereum’s. All of the XLM tokens created at genesis were allocated to SDF, which has full discretion over their distribution. Stellar has no block rewards, but increases supply of XLM 1% annually through an inflation voting mechanism that allows existing stakeholders to earn interest on the coins they possess.

Ethereum’s genesis block allocated less than 20% of the genesis ETH to the Ethereum Foundation, but nearly half of the ETH in existence today has been minted via block rewards earned by PoW miners. The size of the block rewards determines the inflation rate. Ethereum’s primary block reward will be reduced from 3 to 2 ETH in the upcoming Constantinople hard fork. This fundamental change to Ethereum’s monetary policy resulted from an informal governance process that entailed community debate over three competing proposals, a disregarded community poll, and ultimately agreement among roughly 15 Ethereum core developers.

The Constantinople hard fork was scheduled for January 16, 2019, however the day before it would have taken effect Chain Security revealed that an upgrade to reduce gas costs of storage operations would make existing smart contracts vulnerable to reentrancy attacks (like the one that enabled draining all funds from the DAO). In response, “key stakeholders around the Ethereum community” decided to postpone the hard fork and released a statement instructing node operators to upgrade to new versions of the Geth and Parity software. The last minute postponement resulted in about 10% of miners failing to install the upgrade and mining on the Constantinople fork. The swift coordination of 90% of miners might be viewed as a community governance success, but perhaps not to those who lost revenue by mining on the minority chain.

The events surrounding the Constantinople hard fork illustrate that Ethereum governance today is still somewhat centralized, informal, and suboptimal. However, there are coordinated efforts aimed at evolving Ethereum toward a more inclusive and formalized (legitimate) process, even as Ethereum’s thought leaders debate what that should look like.

Stellar’s governance structure is mostly centralized within the SDF, whose board of directors oversee all policy decisions. Institutions who are approved by SDF and make recurring financial donations can become part of the SDF’s Expansion Board and earn the right to participate in some of SDF’s governance processes through voting. Other stakeholders and community members are apparently excluded from this process.

Some amount of governmental power in Stellar can be wielded by anchors, the trusted entities that issue assets on the Stellar network. Anchors enable real world assets to be exchanged on Stellar by issuing digital credits in exchange for deposits of the asset. Users must trust that the issuer will properly redeem the credits and formally declare this trust by creating trustlines to the anchor that holds their deposit. By default, anchors have the ability to authorize and revoke access to the assets they issue. The power to refuse to credit or freeze any account at the anchor’s discretion can be used to support compliance with various regulations and Stellar provides a built-in compliance protocol to enable anchors to comply with Anti-Money Laundering (AML) laws that require these powers. However, Stellar also supports open and non-revokable issuance of assets by allowing Anchors to remove these powers over the assets they issue.

Ethereum, in accordance with its maximally general and featureless design principles has no built-in compliance mechanisms. However, various projects within the Ethereum ecosystem are developing mechanisms to support compliance with anticipated regulations around security tokens. Whether Ethereum will be the top platform for issuing security tokens has a lot to do with the security of the smart contracts that issue and manage those assets.

Smart Contract Security

Whereas most smart contract platforms come with a virtual machine that executes smart contract code written in one or more high level languages, Stellar does not. Stellar smart contracts are just a collection of transactions constructed to work together to perform the intent of the contract. Each transaction consists of one or more predefined operations that can be executed by nodes without the need for a virtual machine. The operations in a transaction execute sequentially, atomically, and deterministically with semantics defined by the stellar-core implementation. By having no virtual machine Stellar avoids a number of safety issues associated with the EVM.

Stellar smart contract developers can satisfy some common financial application use cases by creating transaction sets from a vocabulary of about a dozen operations and setting various constraints on accounts and transactions. For example, consider a multisignature escrow contract that allows Alice to fund an escrow account that disburses funds to Bob after some specified time and allows her to later recover the funds if Bob does not withdraw them in a timely manner. Such a contract can be created from a set of five Stellar transactions using operations that create the escrow account, fund it, set up the signers and signature weights on the escrow account, and set sequence numbers and time bounds on the disbursement and recovery transactions.

The limited set of operations and constraints available on Stellar greatly limits the types of applications and use cases that it can support compared to platforms like Ethereum, which provide general purpose smart contract languages. However, the attack surface on such a highly constrained environment is significantly lower. The more features a language has, the more opportunities for an attacker to exploit surprising interactions of those features. Compare Stellar’s simple multisig implementation to the Solidity implementation of the Parity multisig wallet smart contract. The use cases aren’t identical, but are functionally similar enough to illustrate how attack surface increases with language features. The Solidity implementation, which was authored by Ethereum’s founder Gavin Wood and reviewed by a team of experts, has been exploited twice resulting in large losses of funds both times.

Solidity has a long, and never ending, history of vulnerabilities arising from its numerous features and surprising interactions among them. Just recently, Ethereum’s Constantinople hard fork was postponed at the 11th hour, when it was discovered that a reentrancy vulnerability would be introduced by a seemingly unrelated change to the gas cost of storage instructions. In contrast, Stellar transactions do not use gas metering and the concept of reentrancy (or even calling into another contract) does not exist.

The Etherum community has and will continue to expend a great deal of energy documenting best practices for preventing reentrancy and other Solidity vulnerabilities, but this will never be enough to overcome the massive attack surface arising from the language’s complexity. That the reentrancy vulnerability in Constantinople went undetected by the entire Ethereum community for so long suggests that Solidity is too generalized and full featured to ever be a viable language for smart contracts that control high value assets.

Whereas Ethereum’s next generation Vyper language is aimed at improving security by making the code simpler and less likely to mislead developers and users about its behavior, this step in the right direction may not be soon or large enough. At the time of writing, the percentage of Ethereum mainnet contracts written in Vyper is almost negligible. As long as the vast majority of Ethereum contracts are written in Solidity, there will remain a large number of Ethereum contracts that are vulnerable to all the known and unknown vulnerabilities inherent in Solidity.

Stellar smart contracts take a much larger step toward safety by providing a highly constrained environment that minimizes features and thus vulnerabilities. Stellar’s thesis is that most blockchain applications don’t need the flexibility of a Turing-complete language, “they just want to issue digital assets and process transactions.” Rather than begin with maximal flexibility and evolve toward improved security, Stellar begins with maximal security and will evolve toward greater flexibility as needed.

Stellar’s laser focus on financial applications could lead them to dominate that application space and, in a scenario where blockchain applications are mostly financial, the lion’s share of the smart contracts platform space. However, in order to maintain that dominance Stellar will have to develop increasingly more general features to support increasingly more complex financial and non-financial applications, including scaling solutions. If Stellar does this by expanding its constrained set of operations, it will likely not be able to foresee and implement all the operations necessary to build the next killer apps/scaling solutions, and thus will slow the pace of innovation compared to platforms supporting generalized programming languages. Stellar may be able to encourage innovation on its platform by introducing a more generalized programming language or framework, but it will have to do so in a way that maintains the safety of its financial applications, i.e., by being significantly more constrained than the Solidity/EVM framework.

If confidence in Ethereum smart contracts continues to be eroded by the loss of funds due to Solidity exploits, then projects may look to build their financial applications on a platform that trades some flexibility for increased safety as Stellar does.

Conclusion

Stellar is in many ways different from Ethereum and many of the smart contract platforms examined thus far in this series. Whereas Stellar and Ethereum have very different consensus mechanisms, they both currently achieve low throughput, face somewhat similar scalability challenges, and will address them with sharding and layer 2 solutions. The cost to subvert consensus safety may be lower on Stellar (depending on what architecture for maintaining quorum intersection emerges), but if safety is maintained, instant finality will enable simpler and more efficient sharding on Stellar. Despite having very different monetary policies, the current structure and operation of governance on each platform is roughly the same. When it comes to smart contract security, however, Stellar and Ethereum make fundamentally different design tradeoffs, with Stellar favoring safety and Ethereum favoring general programmability.

Trading flexibility for safety makes Stellar simultaneously an attractive alternative to Ethereum for deploying financial applications and no threat to Ethereum’s dominance as a generalized smart contracts platform. However, achieving dominance in financial applications could lead to network effects that enable dominance in other applications, even if innovation is slowed resulting in inferior applications. However, as Vitalik Buterin points out, innovation in non-financial blockchain applications may outpace financial ones since most can be deployed and iterated on quickly without fear of loss when they break. In a world where mostly non-financial blockchain applications flourish, Ethereum is poised to dominate.

Whereas I am critical of fully generalized smart contract programming languages such as Solidity because of the vulnerabilities and financial damages they incur, I also find it difficult to envision scaling solutions such as Plasma, generalized state channels, and sharding being implemented within the constraints of Stellar’s current smart contract framework. Although it’s likely that Stellar will expand their platform to support certain scaling solutions, the platform will not enjoy the pace of innovation that can occur in a community building on a general purpose platform such as Solidity/EVM.

Stellar, with its leadership track record, solid technology, running mainnet (since 2014), large community, and numerous partnerships and projects around the globe, is currently a viable threat to disrupt Ethereum. However, it appears that its path to dominance as a smart contract platform would come through dominance of financial applications, a position which is firmly held by Ethereum at the present time. Whereas Ethereum’s stronghold may quickly unravel with the next Solidity exploit and/or governance crisis, the platform has been remarkably resilient to such events and remains the prevailing target for financial and non-financial applications.

If you’d like to follow me on Twitter, I’m @edposnak

If you’d like to support this series with an ETH donation, please send it to 0x7e83982eb92502ad5d38c400ba2af7b135469ac9

Your support allows and encourages me to devote more time to these articles and is greatly appreciated.