That's a lot of words to say "this system is insanely complicated for what it does (ie doesn't do)".
Oh, but the details in this case are absolutely fascinating! Well worth all the words IMHO.
Ethereum Is a Dark Forest
11–20 of 463 posts
Re: Ethereum Is a Dark Forest
#12Fantastic story and analogy to Liu Cixin's novel. Writing bug-free code is hard enough, but this adversarial environment is fascinating and takes it to another level.
Not sure if it's covered in the novel but reading this really makes me think these adversarial environments could be very cool hosts for emerging (or seeded and self replicating) intelligent agents some day.
Re: Ethereum Is a Dark Forest
#13Does anyone else think that Solidity is far too low-level for the purpose it serves? I really don't think connecting to ports (as an example) should be something in a financial contract.
It’s far too everything. Too low level, too high level, bad abstractions, bad syntactic constructs, bad evaluation model.
The more I see people burning themselves on “smart contracts” the more I realize how deeply thought through bitcoin’s design is. Creators have thought of so many things in advance, it’s outright creepy.
Re: Ethereum Is a Dark Forest
#14The whole thing is a complicated, wacky game. The DeFi stuff is especially fun right now. Opportunities (and danger) abound. There is so much money locked up in DeFi.
It's not necessarily always good for the bots either. They can be exploited and tricked as well.
Re: Ethereum Is a Dark Forest
#15Does anyone else think that Solidity is far too low-level for the purpose it serves? I really don't think connecting to ports (as an example) should be something in a financial contract.
Yes. They should have gone with something simple and declarative, like decision tables.[1] Those have a finite number of cases and can be exhaustively tested. Which is what you want for a smart contract for something real.
But no, they had to make it Turing-complete. That failed quickly. Remember the DAO debacle. That should have been a teaching moment. But no. Because the people burned were insiders, the whole Etherium blockchain was split to rescue them.
Re: Ethereum Is a Dark Forest
#16Does anyone else think that Solidity is far too low-level for the purpose it serves? I really don't think connecting to ports (as an example) should be something in a financial contract.
What do you mean by "connecting to ports"?
https://solidity.readthedocs.io/en/v0.7.0/search.html?q=port
Re: Ethereum Is a Dark Forest
#17"Because I’m a professional DeFi thought leader, I had never actually deployed a contract to Ethereum before."
Re: Ethereum Is a Dark Forest
#18Does anyone else think that Solidity is far too low-level for the purpose it serves? I really don't think connecting to ports (as an example) should be something in a financial contract.
Yes. They should have gone with something simple and declarative, like decision tables.[1] Those have a finite number of cases and can be exhaustively tested. Which is what you want for a smart contract for something real. But no, they had to make it Turing-complete. That failed quickly. Remember the DAO debacle. That should have been a teaching moment. But no. Because the people burned were insiders, the whole Ether…
How has it failed? Seems to me that turing completeness has allowed Ethereum to flourish.
Re: Ethereum Is a Dark Forest
#19"Because I’m a professional DeFi thought leader, I had never actually deployed a contract to Ethereum before."
Having deployed a contract to Ethereum, I can tell you that it is not for the faint of heart for a variety of reasons too numerous to list here.
If the VM can change, but the code can't, it's gonna be hard to maintain.
Re: Ethereum Is a Dark Forest
#20I wonder how these bots perform the shorting. Do they take the modified instruction and increase miner reward to make it more prioritized than the original transaction? Such a bot would be hard to counter as if you set some reward value, even if it's extremely high, it would take it and increase it by 1. Even if you saw that value yourself and increased it yourself, they could counter your counter by inceasing again, the process continuing until everything is eaten up by miner rewards.
If you have multiple such bots, would they fight over the loot, increasing the reward until it's all given to the miners?
Are there any logs of rejected transactions that existed in the mempool? Is there evidence of such fighting?