4 ms·

What's sad is projects like this and the broader crypto scene (rightfully) turn people off of blockchain and then overlook Ethereum

te_chris 4y ago
No one’s overlooking ethereum, it’s just not that useful to use the worlds slowest, most expensive computer when there is literally any other option for most cases.
- hanniabu 4y ago
  If you're willing to throw out security and use one of the many EVM clones, then you're just better off using a database. You're giving away the main value add and are just left with inefficiencies.
  - KMag 4y ago
    > If you're willing to throw out security and use one of the many EVM clones... The devil is in the implementation details, but if we're talking about eBPF vs. EVM... one of them was designed for deadlock-free execution of untrusted code in-kernel, and the other is EVM. Though, for smart contracts, I think we're best off with a graph reduction execution model, where the contract is presented its initial state and an array of the output contract states, and the contract graph evaluates to True i.f.f. the outputs are an acceptable end-state given the initial state. The client code would propose the new state, along with a compact representation of the path taken through the graph. (The path represented as the index of each branch taken at every OR node in a pre-order traversal of the graph.) The client-side execution to find a True path through the graph might not be efficient, but the on-graph verification is fast, and the format lends itself to a declarative contract description.
    - cfcosta 4y ago
      Isn't this a modified version of eUTXO [1]? Known initial state/datum, transactions can be simulated/commited without needing global input like the account model needs. The tradeoff is, of course, that scripts become much harder to implement, as you can't depend on global state. [1]: https://iohk.io/en/research/library/papers/the-extended-utxo-model/ https://iohk.io/en/research/library/papers/the-extended-utxo...
  - yieldcrv 4y ago
    If only I could use a database where all my users pay for all traffic to it
TechBro8615 4y ago
Solana is quite cool from an engineering perspective. It's built with Rust and you compile programs to BPF for execution on the decentralized VM. https://docs.solana.com/developing/on-chain-programs/overview https://docs.solana.com/developing/on-chain-programs/overvie...
- hanniabu 4y ago
  Alt L1 VC chains have completely milked and diluted the term "decentralized" from the original meaning. Solana is not sufficiently decentralized.
clpm4j 4y ago
I know very little about Ethereum, but if I wanted to develop some application on top of it, would I still need to write Solidity or are there ways around that language now?
- em_te 4y ago
  Like all web apps it depends on how much you want to do on the client side vs. the server side. With blockchain apps it is now client side vs. server side vs. blockchain side. At one extreme, apps like UniSwap are mostly blockchain side and server side code and a little client side. At the other extreme, it is possible to use boilerplate code to write a minimal blockchain part and then have most of your business logic on your own server and then the UI on the client side.
- dboreham 4y ago
  There are other languages that compile to EVM bytecode, but: probably yes.
  - ChainOfFools 4y ago
    none of them are ad aptly named as Pyramid Scheme[0] [0] http://www.michaelburge.us/2017/11/28/write-your-next-ethereum-contract-in-pyramid-scheme.html http://www.michaelburge.us/2017/11/28/write-your-next-ethere...
- pa7x1 4y ago
  There is also Vyper and Fe. But they are both much less mature, probably not recommended for production.
NotYourLawyer 4y ago
Yes. Tragic.
julianeon 4y ago
The problem with Ethereum is that transaction fees are just too high. And if you say L2 like Polygon, then I think it's fair to counter: rather than having multiple layers, it's better to have just one layer, which is fast enough. That was the value prop of Solana. I'm not sure they're delivering (the real problem) but, stated that way, as an attempt at a solution, it makes perfect sense.
nailer 4y ago
Eth is slow and expensive.

te_chris 4y ago

No one’s overlooking ethereum, it’s just not that useful to use the worlds slowest, most expensive computer when there is literally any other option for most cases.

hanniabu 4y ago
If you're willing to throw out security and use one of the many EVM clones, then you're just better off using a database. You're giving away the main value add and are just left with inefficiencies.
- KMag 4y ago
  > If you're willing to throw out security and use one of the many EVM clones... The devil is in the implementation details, but if we're talking about eBPF vs. EVM... one of them was designed for deadlock-free execution of untrusted code in-kernel, and the other is EVM. Though, for smart contracts, I think we're best off with a graph reduction execution model, where the contract is presented its initial state and an array of the output contract states, and the contract graph evaluates to True i.f.f. the outputs are an acceptable end-state given the initial state. The client code would propose the new state, along with a compact representation of the path taken through the graph. (The path represented as the index of each branch taken at every OR node in a pre-order traversal of the graph.) The client-side execution to find a True path through the graph might not be efficient, but the on-graph verification is fast, and the format lends itself to a declarative contract description.
  - cfcosta 4y ago
    Isn't this a modified version of eUTXO [1]? Known initial state/datum, transactions can be simulated/commited without needing global input like the account model needs. The tradeoff is, of course, that scripts become much harder to implement, as you can't depend on global state. [1]: https://iohk.io/en/research/library/papers/the-extended-utxo-model/ https://iohk.io/en/research/library/papers/the-extended-utxo...
- yieldcrv 4y ago
  If only I could use a database where all my users pay for all traffic to it

TechBro8615 4y ago

Solana is quite cool from an engineering perspective. It's built with Rust and you compile programs to BPF for execution on the decentralized VM. https://docs.solana.com/developing/on-chain-programs/overview https://docs.solana.com/developing/on-chain-programs/overvie...

hanniabu 4y ago
Alt L1 VC chains have completely milked and diluted the term "decentralized" from the original meaning. Solana is not sufficiently decentralized.

clpm4j 4y ago

I know very little about Ethereum, but if I wanted to develop some application on top of it, would I still need to write Solidity or are there ways around that language now?

em_te 4y ago
Like all web apps it depends on how much you want to do on the client side vs. the server side. With blockchain apps it is now client side vs. server side vs. blockchain side. At one extreme, apps like UniSwap are mostly blockchain side and server side code and a little client side. At the other extreme, it is possible to use boilerplate code to write a minimal blockchain part and then have most of your business logic on your own server and then the UI on the client side.
dboreham 4y ago
There are other languages that compile to EVM bytecode, but: probably yes.
- ChainOfFools 4y ago
  none of them are ad aptly named as Pyramid Scheme[0] [0] http://www.michaelburge.us/2017/11/28/write-your-next-ethereum-contract-in-pyramid-scheme.html http://www.michaelburge.us/2017/11/28/write-your-next-ethere...
pa7x1 4y ago
There is also Vyper and Fe. But they are both much less mature, probably not recommended for production.

NotYourLawyer 4y ago

Yes. Tragic.

julianeon 4y ago

The problem with Ethereum is that transaction fees are just too high. And if you say L2 like Polygon, then I think it's fair to counter: rather than having multiple layers, it's better to have just one layer, which is fast enough. That was the value prop of Solana. I'm not sure they're delivering (the real problem) but, stated that way, as an attempt at a solution, it makes perfect sense.

nailer 4y ago

Eth is slow and expensive.