As i noticed some projects going to launch ICOs on Stratis? Does they have some advantages before competitors? (ETH, NEO, EOS etc.) How many TPS here?
Firstly, I guess it's important to point out that the Stratis ICO Platform is blockchain agnostic, so a project running an ICO through the Stratis ICO Platform is not limited to issuing a token on top of any one blockchain, but can instead choose that which they think suits them best. So that out of the way, we can look into some advantages/disadvantages of building on top of Stratis.
Transactions per second is a measure of throughput. Tps is an average taken over the block interval (txs per second = number of txs in a block / block interval in seconds), so it doesn't necessarily tell us a huge amount about the capabilities of a blockchain, but it is an easy to grasp measure to give us some sense of the capability of a blockchain at the blockchain level. Obviously, this measurement becomes meaningless as you move on to second layer techs.
For Stratis, the achievable throughput is effectively indefinite since the Stratis ecosystem employs sidechains, blockchains which are pegged to the Stratis mainchain in such a way that the coins of the sidechain in effect become Strat themselves. This means that it is possible to use Strat on a whole new blockchain, with different consensus rules, parameters etc. from the Stratis mainchain itself. If (for some reason) you need a higher throughput than is currently achievable in the Stratis ecosystem, you can create a new sidechain which gives you the throughput threshold you need. For most applications, this will be completely unnecessary, but it's good to know that it is an option.
The question you've raised, behind the question about transactions per second, is why Stratis over the competition? EOS and NEO both have such huge architectural problems (IMHO) that we can ignore them and concentrate on ETH vs Stratis, since ETH is in a league of its own above EOS and NEO.
To this end, here's a little ETH vs. Strat breakdown from my perspective, concentrating on the two main differences:
Solidity/EVM vs. C#/CLRBitcoin started it all off and had the first smart contracts. Using a purpose built language called Script, developers could build “smart contracts” which are basically a set of conditions which must be met in order for a transaction to be valid. For example, a very common smart contract is the multisig contract. This basically requires more than one signature to be valid. Thus, a smart contract is simply “money can move from
here to
here so long as this set of conditions is met in such a way that execution of the contract comes out “True””.
Bitcoin’s Script language is very limited by design and it is not Turing complete. Turing completeness refers to whether or not a language can be used to simulate any Turing machine. Non-Turing-complete languages are usually built for a very specific set of applications, whereas Turing-complete languages are usually designed with broader set of applications in mind.
Ethereum wanted to take the set-of-conditions-under-which-a-transaction-becomes-valid to the extreme and allow developers to build any non-trivial applications, all based around this idea of smart contracts. To do so they created their own virtual machine, the EVM, and designed an accompanying Turing-complete language called Solidity.
So why build the EVM and then design a language to suit that particular operational environment? Smart contracts offer a unique set of challenges. There are LOADS of considerations for smart contracts, you can’t have loops, must be deterministic, smaller code is better etc. Adapting existing virtual machines to smart contract development is a monumental task.
So the cheap answer is: building the EVM and Solidity from scratch was the easiest way of delivering on Ethereum’s promise of providing smart contract development with a Turing-complete language with sufficient confidence in security. (For a more complete answer, read through Buterin’s replies here:
https://answers.thenextweb.com/s/vitalik-buterin-13gxQB)
The trade off is developers now have to use an unfamiliar operational environment. As Jordan Andrews (lead smart contract developer at Stratis) says: “frustrated with the “young” state of solidity and Ethereum smart contract development environments, I started craving bringing my favourite development environment (C# / .NET / Visual Studio) to blockchain development.” (
https://hackernoon.com/a-token-smart-contract-executing-in-native-net-and-92ceaf972713) The .NET ecosystem is one of the best populated development environments that exist today, both in terms of tools available to devs and in terms of community support.
So, allowing smart contract development with .NET’s own VM (the CLR) is hard, but if the trade off is worth it? How come no one did it earlier? Well, in this case, Stratis has first mover advantage. CLR only became open source in 2015, and Stratis started out building on top of NBitcoin (C# implementation of Bitcoin built by Dorier, starting in 2015) so in some sense Stratis started life at the
earliest possible moment.
In the years since, they’ve managed to deliver smart contracts with that promise; Developers can now:
- Create SCs in a familiar environment (.NET framework). Smart contracts already require devs to learn a whole new way of thinking about application engineering due to the constraints of achieving peer-to-peer consensus. Forcing them to learn a new language/dev environment raises that barrier to entry yet higher. With Stratis, that is not the case.
- .NET code which executes on chain. This means that Stratis smart contract code will behave in the same way as in any other C# application. Something which cannot be guaranteed when using a custom virtual machine (looking at you, NEO…).
- Access to all of the tools and broader benefits of the .NET framework, including established best practices, security auditing of code (made even easier since the code can be decompiled direct to the C# source code), fantastic support from the millions-strong C# dev community.
Stratis chose the hard option because they believe that the benefits outweighed the costs. There will be people who will make a strong case against Stratis’ decision. It’s not easy to take an unbiased position, so I think we will have to go the “the proof will be in the pudding” route and see how Stratis’ smart contracts stack up in terms of dev adoption.
It must also be said that executing CLR code comes with other challenges with regards to achieving consensus amongst executing nodes, and talking to ETH devs you'll get a few criticisms of this solution along these lines. These challenges required Stratis met them head on with solutions such as the coming Whitelisted Smart Contracts. Whitelisted Smart Contracts are the current solution and will be replaced by a more elegant solution in due course.
Deploying to mainchain vs. Deploying to sidechainsTo do this part of the discussion justice we have to do some thinking about what a blockchain is. Not about what it does, or what it enables, but what it actually
is (caveat - the following is an analogy: a heuristic to better communicate my point. As such, it is a model and we should bear in mind that “all models are wrong, but some are useful”. Hopefully this is useful).
A blockchain is waste. A blockchain is a necessary, but unfortunate, waste by-product of achieving peer-to-peer consensus on the system state of a cryptocurrency. A blockchain is not something you want, it’s something you need to get mutually untrusting parties to agree about the state of a cryptocurrency, i.e. where all the money is, the history, all information existing in the crypto itself. If it were possible to achieve true peer-to-peer consensus about the system state of a cryptocurrency without a blockchain, then it would be preferable to do so. However, it seems that it is not possible.
Over time this waste gets bigger and bigger and sometimes the waste is being produced at such a rate that it makes the cryptocurrency difficult to use.
We can usefully take the analogy further: a blockchain is a pile of waste and more waste is added to the pile with every block. Sometimes, so much waste is being produced at once that it becomes difficult to process it and more waste is being produced than is able to be added to the big blockchain pile. We’ve seen this happen with Bitcoin and Ethereum. Transaction fees were being pushed up by the mechanics of competition as congestion overwhelmed “waste management” and people were willing to pay higher prices to have their waste processed first.
Smart contracts compound this. A blockchain can become bogged down by smart contracts and by the transactions associated with smart contracts (plus things like Airdrops etc.). Smart contracts produce a lot of waste and it tends to be that the more sophisticated the smart-contract-based application, the more waste it produces.
The difficulties faced by Ethereum last year are prime examples of this. Smart contracts were making Ethereum unusable for large periods of time. As adoption grows, so too will the difficulties facing cryptocurrencies which do not have in place some sort of scaling solution.
Stratis’ solution is sidechains. A sidechain is a blockchain which is pegged to the Stratis mainchain in such a way that Strat must be locked up in order to use the sidechain. In this way, you can think about Sidechain as being a completely different blockchain which actually uses Strat! It’s a really neat solution. When you’re using a sidechain, you’re effectively using Strat but on a completely different blockchain (but it won’t say you’re using Strat, you’ll be dealing with the coin native to the sidechain, which will no doubt be called something else, but this coin cannot exist unless you lock Strat up in return). Thus all the waste is offloaded to a completely different pile, instead of being heaped onto the Stratis waste pile.
The Stratis mainchain does not support Stratis Smart Contracts. Only sidechains can be Stratis Smart Contract enabled. Thus all waste associated with Stratis smart contracts will be heaped onto sidechain waste piles rather than onto the Stratis waste pile. This means that the Stratis mainchain itself is left free to go about its business of processing transactions and maintaining the underlying economy to the Stratis ecosystem.
Ethereum has no such scaling solution. In my opinion, this is a much more clear cut advantage for Stratis.
