For the past year, Opensolar has transitioned from an Ethereum based MVP platform to a more robust Stellar based platform. Through working with partners and talking to multiple people working on similar projects, we have come to understand deeply about what the advantages of using Stellar are, along with a broad list of disadvantages. Most of these have been discussed in some capacity before but it makes sense to have all in a single place in order to reference this list later on.
Stellar follows an account based system similar to Ethereum. Stellar supports 13 operations (https://www.stellar.org/developers/guides/concepts/list-of-operations.html) and each of these options has a variety of applications that it is used for. Here, we list the operations used in the opensolar platform.
- Create Account: To create user accounts on the platform
- Payment: To move money between different accounts
- Buy Offer: To exchange XLM and other currencies on the Stellar DEX (buy)
- Sell Offer: To exchange XLM and other currencies on the Stellar DEX (sell)
- Set Options: Multisig, Escrow accounts
- Change Trust: Multisig, Escrow accounts
Aprt from these operations, we use Stellar Assets (https://www.stellar.org/developers/guides/concepts/assets.html) to issue assets to investors and recipients, in order to replicate the notion of state variables in ohter blockchains. These assets need
- An issuer: To issue the asset in question. In our case, the issuer is the platform
- A receiver: A receiver creates a trustline between itself and the issuer. The trustline indicates how much the receiver trusts the issuer for. (For example, you may trust a given issuer for 1000USD but not for 10000USD)
Assets are used to track the amount owed by the receiver, and in the case of investors are 1:1 with the amount of returns they are expected to get. For receivers, there are two types of assets - one to track how much the receiver owes to fully own the project and the other to track expected months to ownership depending on their payments back to the platform.
- Easy to use SDK: The Stellar SDK is easy to use, moderately documented, making it easy to use it to interact with the blockchain. The current backend makes extensive use of the API in order to perform operations on transactions, accounts and similar. The Stellar Go SDK is also under active maintenance and it makes it easy for us to write security critical applications in Go.
- Centralized Horizon API: The Horizon API acts as a remote node for the platform and allows the platform to submit transactions to be published on Stellar. Most of the network has the Stellar Foundation's nodes in its quorum and we follow a similar model. We used to run our own nodes but as mentioned before, most nodes have the SDF nodes in their quorum so it makes more sense to connect to these nodes to get a view of consensus.
- Easy P2P assets: Having assets allows us to explore more functionality at little cost and we could model entire platforms based on the notion of P2P assets. P2P assets are used by the platform to keep track of investor investments and receipient debts and ownership record.
- Easy primitive modeling: A combination of Horizon and the Stellar Go SDK make it easy for us to construct basic things which are needed to contruct primitives on the platform. This includes multisig escrows, signers with different weights and more.
- Small ecosystem: The Stellar ecosystem kickstarted in 2014 has a limited developer / partner ecosystem. As a result, finding partners that can help the platform (eg. providing onboarding services) are difficult, and in some cases really expensive. This can further be expanded into the following sub-categories:
- The lack of onboarding infrastructure: Stellar's on and off ramp presence is restricted to two companies (AnchorUSD and StrongholdUSD) working in the space. AnchorUSD is a company out of YCombinator and supported by grants from the Stellar foundation, and Stronghold is a company funded by IBM. We reached out to both firms. StrongholdUSD charges $10000/mo for using their stablecoin and KYC services. AnchorUSD does not charge us anything for using their services as of now. AnchorUSD's APIs and infrastructure are structured around the company itself, making integrations with respect to UI and UX difficult. Alternatives to the above companies do not seem to exist nor do they seem to be in the works to gravitate towards. This presents a problem in the short and long term since it places sufficient trust on the above company for stablecoin services (if Anchor shuts down, we have no stablecoin service, Anchor might just shut down whilst we are in the middle of a project and participants might be unable to exchange XLM for SUD without transferring to an exchange for example).
- Lack of liquidity and absence of major infastructure: AnchorUSD is not listed on exchanges and liquidity for the USD/XLM pair on the Stellar DEX is low (10000 USD before an exponential drop in price). This makes investments greater than 10000USD a major problem since such an order by itself can move the order price. The overall lack of infrastructure for buying XLM is a broader concern since only BTC/ETH/XRP seem to have readily usable onramps for their respective currencies.
- Lack of developer support infrastructure: When developing on a platform, it is critical to be able to connect with other people working on similar platforms. Ethereum is a good example of a robust developer ecosystem. With Stellar, developer infrastructure seems to be limited, and this is an issue when we scale up and look for more developers to work on the core platform (and as a consequence, on Stellar itself). This is also a problem when we need something to be developed on the Stellar SDK or when we find a bug and require it to be fixed.
- Lack of advice on best practices: The Stellar dev team's help in the development of Opensolar has been minimal and having the help of the core team on best practices, having them review the platform and give feedback is essential in order for the platform to do better.
- Limited functionality: While Stellar is good in what it offers, its functionality is limited to that designed by the Stellar team. Some examples of future improvements that would be great to have are on chain smart contracts and verifiable proofs of execution, which would be nice to have if the platform can aim to be truly trustless. Considering that Bitcoin, a platform viewed to be traditionally restrictive by nature, has more features than Stellar, there is room for expansion.
- Security issues: The Stellar blockchain halted for about 4 hours in May 2019 and was attributed to a crash in the SDF's nodes. Given almost the entire network uses default quorums (which trust SDF nodes), this places a barrier on consensus and halted the overall network. In the short term, this is not a big concern since orders placed on the platform are of relatively lesser value. But as we scale and have bigger orders on the platform, this becomes an increasing concern.
The primary effect of these disadvantages is felt more on the user experience side than on the technical side. Given there are no reasonable alternatives to AnchorUSD, users are forced to go through a bad user experience draught with delays in order to just be able to invest on the platform. The UI/UX of AnchorUSD doesn't help in this process either, given the website's overall feel.
The Advantages/Disadvantages combination of Stellar leads us to look for alternate platforms which can offer a better combination of both. Such a transition would take time, and careful evaluation, the grounds of which we aim to lay in the following sections.
In order to evaluate between different platforms, we would need to define what goals we would like the platform to have. Broadly, the goals that we seek for the platform are:
- Easy to use interface: The platform must be easy to use, with simple language and steps needed to both invest in, and be part of the platform.
- Trustless: The platform must minimize trust in itself as much as possible to avoid attack vectors around itself.
- Secure: The platform must be backed by strong security guarantees (in our case, a secure blockchain).
- Robust functonality: The platform must be able to perform its intended set of functions in an easy, fast and secure manner.
- Easy user onboarding: Users must be able to get on the platform as easily as possible, with minimal steps required.
There are more goals which are outlined in the following Google Sheet: link. This sheet aims to explain the advantages, disadvantages and status of each blockchain and the Google Sheet aims to quantify these measurements into a model which can be relied upon for a final decision.
Since we want the base layer platform to be secure, there are a limited number of blockchains that satisfy the given criteria. We omit contentious blockchains like Bitcoin Cash and Bitcoin SV, whose development is highly volatile and centralized to a limited number of people in the ecosystem. We also omit contentious blockchains like Tron, Ripple, and EOS.
- Bitcoin
- Ethereum
- Algorand
- Hyperledger
- Cosmos
- AVA
Bitcoin uses an unspent transaction output model. Bitcoin has a host of operation codes that can be used to perform a variety of operations on top of the Bitcoin protocol.
- Most secure blockchain: Bitcoin boasts the best security amongst all blockchains.
- Good developer ecosystem: Bitcoin's developer ecosystem is second to that of Ethereum and has developers working on lots of interesting applications on top of Bitcoin. Layer 2 (L2) and Sidechains present interesting potential for the platform in terms of increasing throughput and modelling P2P assets similar to what we have now.
- Good research: There are tons of applications that are being actively researched into on top of Bitcoin, and developing these ideas might prove to be interesting for expanding the platform beyond what it is right now. Some interesting future changes on top of Bitcoin are Taproot and Schnorr signatures.
- Best onramps and stablecoins: Bitcoin has the best onramp infrastructure among all blcokchains given its widespread popularity and reach. There are direct traditional method onramps (CC/DC/Check/Wire) and decentralized alternatives (DEX) that are built on top of Bitcoin with great liquidity. Stablecoins like Tether are Bitcoin native and have good onramps given the exchanges they are created by.
- Good access to resources: Given we have core developers who work on Bitcoin at the DCI, access to expert opinions and suggestions is not a problem. Core developers are easy to reach through different methods and can be contacted in the event we need help on specific parts of the platform.
- Complex opcode infrastructure: By design, it is difficult to construct things that are simple in other blockchains like Stellar. Things like multisig must be designed using basic Bitcoi nScript primitives before they can be used readily.
- Expensive: Bitcoin transactions are expensive and since Bitcoin does not have a virtual machine, transaction updates must be batched together to prevent fee explosion. Bitcoin is still cheaper than something like Ethereum which has a secondary fee market powered by "gas".
- Lack of Go SDK: Bitcoin Core is written in C++ and most tools are either in C++ or Javascript making it difficult to model primitives directly in Go. We would need to write handlers in Go that speak to Bitcoin Core if we are to still use Go as the backend.
- Limited features: While Bitcoin has a good set of features and a good L2 infrastructure, it is not as robust as Ethereum which boasts a Turing complete virtual machine. L2 and Sidechains help extend functonality of Bitcoin but Turing completeness is exclusive to Ethereum.
- Time to develop: The platform is customised for an account based model right now, so transitioning to Bitcoin would mean that major parts of the backend are rewritten with a focus on the transaction output based model.
- Lack of developer resources: While access to expert opinions is not an issue, developers in the Bitcoin space are limited so it would be difficult to find people who have worked with Bitcoin in the event we need to hire more developers to work on the platform.
Ethereum uses an account based system similar to Stellar. Ethereum hosts a Turing complete Virtual Machine which can be used to deploy arbitrarily complex smart contracts on chain. Ethereum boasts the largest developer ecosystem among all blockchains.
- Turing complete Virtual Machine: Ethereum's most unique feature is its smart contract execution machine that can be used to deploy complex smart contracts executed on chain. As long as the "gas" used by the smart contract is less than the defined gas limit per block (8 million), the smart contract can run on chain. This is immensely helpful for providing proofs of execution and storing variables on chain.
- Huge developer ecosystem: Developer resources are plenty in Etheruem, and there are resources to borrow from in the event Opensolar needs to adopt new functionality. The huge talent pool also means that it is easy to hire developers to work on the platform.
- New developments and research: Ethereum is a hotbed for new research developments which can be used to augment the platform. Cutting edge research like Zero knowledge proofs, proof of stake, etc. are theorized and developed on Ethereum, which can benefit the platform in terms of functionality.
- Good onramps and stablecoins: Ethereum has some of the best infrastructure in the cryptocurrency space with respect to onramps and stablecoins. Decentralized stablecoins like DAO make it possible for the platform to expand beyond traditional territory. Centralized stablecoins like USDCoin that are Ethereum native make onboarding via traditional means easy.
- Transition to Proof of Stake: Ethereum has a five phase roadmap to transition to Proof of Stake and the first phase is slated to take place over the next year. The transition to PoS brings in an excisting set of opportunities for hte platform and might be worht exploring into.
- Good integration with other blockchain systems: Ethereum can easily interface with Bitcoin, Cosmos, IPFS and more.
- High fees: Due to Ethereum smart contracts being deployed on chain, the contract is forced to pay transaction fees for third party interactions with the platform. This could be reduced through future improvements on the Ethereum ecosystem like sharding but as of now, fees are a major concern.
- Smart contract bugs and hacks: Since smart contracts are publicly visible on the blockchain, any vulnerability leading to a loss of funds can be exploited on chain. The Parity multisig hack and the DAO hack are examples of major hacks on Ethereum infrastructure. This can be mitigated through frequent audits but this takes time and costs resources.
- Time to develop: The platform as is right now is customized for an account based system and moving to Ethereum would necessitate that the entire backend be coded from scratch with a focus on Ethereum (similar to how the transition from Ethereum->Stellar happened).
- Transition to PoS: Ethereum is slated to move to a PoS based system in the next year, so it would mean that we would need to re-develop smart contracts to work with the new system (since backwards compatibility might not be assured).
- Difficulties in running archival nodes: We would need to run our own nodes to have a view of the network since Ethereum is sufficiently decentralized. Running an Ethereum archival node is difficult and consumes a considerable amount of resources (>2TB storage, >32G RAM).
Algorand is a Proof of Stake blockchain which follows an account based model. The core consensus algorithm was developed at MIT, by Turing Award winner Silvio Micali. The consensus algorithm follows a leader election, and the leader chooses which transactions are included in a block interval. Its mainnet launched in the last 6 months but it has received criticism over its falling price and relatively small developer ecosystem.
- Proof of Stake blockchain: Since Algorand is a PoS blockchain, it gives rise to an interesting set of features which could potentially be added to the platform. This has more benefits in the short term than Ethereum which would take longer to transition to a PoS system.
- Rapid development cycle: Algorand has a stellar team which is actively working on protocol improvements. In the past year, they have shipped a lot of features.
- Funding Ecosystem: Algorand is looking for and rapidly funding projects that build on top of it. While this is not an immediate concern for Opensolar right now, having access to and support of the core team enables fast development on top of the platform.
- Native Go SDK support: Algorand's primary client SDK is written in Go, so it makes it easy for development using current resources.
- Not time tested: Algorand is a relatively new blockchain and its mainnet is only 6 months old which means that its security properties are not as tested as something like Bitcoin or Ethereum.
- Small developer ecosystem: Even though Algorand seems to fund developers who want to build on top of it, the developer ecosystem around it is small and there aren't many resources to reach out to if we need help. Access to the core team and developer resources might be easier given we're at MIT but the potential of the developer ecosystem remains to be seen.
- Zero onramp infrastructure: There are currently no stablecoins that are Algorand native and there are very few onramps that allow one to buy Algo directly using conventional means. Algo is listed on Binance and the Algorand team stresses they will be added in the future but concerns such as liquidity seen in Stellar still remain and this may not prove to be something concrete that we can trust and build a robust platform on.
- Fizzle Effect: Many blockchains in the past have had rapid development in the first year of their inception only to fizzle out later due to multiple factors. Algorand is well funded and is headed by a good team but there is no guarantee that it will not fizzle out.
- Unknown Smart Contract support: Algorand recently developed a new language for people to build smart contracts on Algorand but it remains to be seen whatk ind of smart contarcts can be built on top of Algorand.
- Not open source: The core Algoran consensus algorithm is closed source and applications that build on top of Algorand should sign a license or something similar. This is a concern when looking to develop an entirely open source platform.
Hyperledger is a framework that can be used to create custom blockchains. There are two primary Hyperledger blockchains right now - Sawtooth and Fabric. Fabric and Sawtooth are permissioned blockchain systems but Sawtooth can be configured to work in a permissionless setting too.
- Permissioned system: Hylerledger is designed to work in a permissioned system and designing such a system is easier and you can closely contorl multiple parts of user experience. It also enables us not to trust third party vendors for stablecoins and other services.
- Permissioned system: Hyperledger is designed to work in a permissioned setting, making trustless applications not possible by nature of the platform. This has a host of disadvantages, the primary being that participants should now trust the platform on certain aspects.
- Slow development: Protocol development is slow like Stellar, and new features are being added at aa very slow rate. While slow development is not a problem with something like Bitcoin where mass consensus is neded for changes, it is a problem for Hyperledger whose audience and reach is smaller. Similar to Algorand, development might fizzle out too.
- No access to expert resources: Due to the slow development pace, the core team routinely shifts in position and it is difficult to find a dedicated team working on features that improve on the protocol layer.
- Zero onramp infrastructure: Since Hyperledger is focused on a permissioned setting, the system assumes that the same actors can be trusted to on and off ramps. While this is not bad, this puts pressure on the platform to develop and maintain this functionality.
- Minimal developer ecosystem.
- Time to develop: Hyperledger is focused on a permissioned model which means the platform's backend will have to be rewritten from scratch since it was developed with a focus on trustless systems. Given the lack of talent pool in the Hyperledger ecosystem, it is difficult to find experts who can do this.
- Legal hurdles: There are legal hurdles that come with developing a permissioned system like gaining license to perform certain functions that are performed by other firms in permission-less settings. With this comes increased maintenance costs associated with the platform itself.
- Unknown shelf life: Hyperledger seems to be slowing in development pace and might eventually fizzle out given the lack of support. This is a factor to be kept in mind whileduring development.
Cosmos is a blockchain of blockchains infrastructure projects aiming to be a common ground for all blockchains. It does not have a native blockchain but focuses on integrating multiple blockchains with the help of its consensus algorithm.
- Good developer ecosystem: While the number of developers working on Cosmos are not as high as something like Ethereum, they are higher than other competing blockchain systems (like Stellar, Algorand, Hyperledger, etc). This leads to a good pool of talent we could tap into in the event we need to scale and get more popele to work on the project.
- Good research: Cosmos has done great research on Proof of Stake systems and is a good example of a PoS blockchain being out in the wild. This presents an interesting set of opportunities we could tap into.
- Partner projects working on similar goals: There are climate change and impact projects which are building on top of Cosmos and building out platform on top of Cosmos would mean that it is easy to integrate with these projects.
- Integrations with other blockchains: Cosmos by design aims to integrate with multiple blockchains so its easier to integrate with other blockchains in the system.
- Native Go SDK: Cosmos' SDK is Golang native which makes it easy to develop on top if we plan on using Golang in the future.
- Lack of onramps and stablecoins: Cosmos has a lack of onramps to both its blockchain of blockchains infrastructure and its native coin ATOM. There are currently no Cosmos native stablecoins and this makes it difficult for onboarding people onto the Cosmos blockchain.
- Smart contract infrastructure not detailed and very fuzzy: There is little mention of the smart contract functionality offered by Cosmos and this makes it difficulty to develop something concrete on top.
- Blockchain not time tested for security guarantees.
- Time to develop: The platform assumes that there is a single blockchain to connect to and perform operations. Shifting to Cosmos would mean a major architectural redesign.
- No access to expert resources: Since Cosmos development is heavily decentralized, different people work on different parts and it is difficult to connect to a team which is working on something that we would be interested in.
- Not time tested: Cosmos is a new blockchain and its entire host of features has not been sufficiently tested in the wild yet.
AVA is a blockchain which builds on top of the Snowball consensus algorithm. It is developed by a Professor team lead out of Cornell. It relies on a broad gossip based consensus and is focused on blockchain throughput and scalability.
- Proof of Stake and Throughput focused blockchain: Since the blockchain is focusd on throughput, it can be assumed that blockchain fees would be low. Since AVA plans to support smart contracts, this would mean the cost of deployed smart contracts is low.
- Focused on applications: AVA is headed by a team which is focused on applications, so it is good to assume that AVA will provide functionality that is targeted towards application developers on top of AVA.
- Access to expert resources: Since the DCI has relatively good connections with IC3, it might be easy to consult expert opinion for developing on top of AVA.
- Closed source code / in development: The codebase source is not open so there's no way to evaluate the devleopment process of AVA. There is also no clarity on whether building on AVA would require a proprietary license or similar.
- Blockchain not developed yet: AVA has not released on mainnet yet, and there is no guarantee that it ever would.
- No response to outreach: We did reachout to gain access to the AVA testnet but there was no response from the AVA core team. This mightbe due to the large amount of interest in AVA but there's no way of knowing if this is really the case.
- No stablecoins / onramps: A natural consequence of the blockchain being underdeveloped and not being released on mainnet. Looking at other blockchains like Algorand, it might mean that stablecoins and the like don't arrive until after 2 years.
- Developer ecosystem unknown: Since the blockchain is not on mainnet yet, there is no way to evaluate how many people would be interested on building infrastructure on top of AVA. This might be a small concern given we have access to the core team building on AVA but in the longer term if there is lesser adoption, it would be difficult to look for developers working on top of AVA.