4 ms·
I really love Ethereum and have been invested in it for a while. I think @vbuterin and crew have a clear idea as to how to move past problems, and I find it ex
by SirensOfTitan 9y ago
I really love Ethereum and have been invested in it for a while. I think @vbuterin and crew have a clear idea as to how to move past problems, and I find it exciting to watch the Ethereum foundation execute their vision well.
Bitcoin, on the other hand, doesn't perform its simple functions well in the short term, and seems to have very little idea on how to scale long term:
1. Transactions are still pretty expensive and take a good while to settle.
2. Proof of work as a long term consensus strategy just doesn't work. The amount of energy required to mint transactions is immense.
3. Bitcoin hasn't made the headway with corporate partnerships that I think will be critical for larger adoption.
On Ethereum's end: a movement to proof of stake, sharding with global consensus, and the corresponding lightening and whisper networks all are really exciting domains of exploration. My two primary worries here are:
1. There has not been much work yet to bring well designed languages to the EVM at this point. Well designed languages, with good testing frameworks (QuickCheck from the Haskell landscape comes to mind), and formally verified fundamentals (e.g. wallets) are critical for contracts to be viable for anything other than playthings.
2. I worry about regulation totally hammering down innovation in this arena before it can sufficiently get past the rough early days. I do cautiously applaud Russia's hesitance to regulate, in an attempt to avoid destroying innovation.
On (1), I would love to get involved writing adapters for languages or subsets of languages like OCaml or Haskell to compile down to the EVM. If anyone knows of any resources I could jump into to explore this type of project, I would love it if you linked them.
- ufo 9y agoSmart contracts are an inusual programming environment, both in termos of what you are doing (managing state transitions, etc) and computing resources available (CPU and RAM are very expensive). I suspect that this is better solved by more domain specific languages instead of an existing FP language
- SirensOfTitan 9y ago> I suspect that this is better solved by more domain specific languages instead of an existing FP language I don't disagree, but with the current state of current Ethereum languages: Viper and Solidity, I feel as though using the good thinking in an existing well designed language might be more worthwhile to explore in the short to medium term.
- deleted 9y ago[deleted]
- qznc 9y agoFormal verification is critical. Projects like this are necessary: https://github.com/pirapira/eth-isabelle https://github.com/pirapira/eth-isabelle Paper: https://yoichihirai.com/malta-paper.pdf https://yoichihirai.com/malta-paper.pdf