This could be pretty interesting for efficient materialization of state in CQRS type architectures. Imagine building/rebuilding state, such as a cache, for a certain region in 1/100th of the time, as you can avoid reading and filtering out records that you do not care about.
That’s fine, and makes sense, but without hacks, it is not possible to turn on ret checking in your tests that are not generative tests - so no post condition checks in the rest of your test suite.
I believe this is a missed opportunity to find bugs.
I agree, and this is not to mention that a lot of the companies funding Mozilla that may love not to pay them, but they have to because there is a viable independent company that provides a browser.
I am glad that Mozilla exists, and I was glad that they existed even when I used Chrome (pre Firefox Quantum).
The dynamic fees you mention are a client side default that may be a good heuristic for client side transaction pricing but has precisely 0 effect on which transactions a miner will include in a block, which will purely choose the highest price transactions. Furthermore, the price is in terms of monero, so sure, you may be paying less monero but it’ll still price out stuff like microtransactions as the fiat price goes past tens of cents.
When I say there is a limit to block sizes, I am referring to the factors, lag, etc, you mention. I believe monero has had to change the block times in the past, as too many orphans were occurring, and block size is another dimension that this will occur on, as it affects the latency of communicating the blocks.
Monero is great, but once you factor in the larger transactions I am extremely doubtful that you could get a higher throughput from it than bitcoin.
I’m a fan of monero, but transaction fees do not decrease as more transactions occur. There are limits to how big the blocks can grow, and also how quickly they respond to demand, and at the end of the day the transaction price will go up as demand increases.
Better techniques are required. Solidity is clearly not ready to be used to secure billions of dollars that can be anonymously stolen in an instant. Fuzz testing should be an absolute minimum. Formal proofs, and a simpler language should be the ultimate goal.
Hopefully the ethereum foundation takes note because this problem is not going away, and they are responsible for 20B$ market cap of value. I realise that ethereum is still young but they have chosen to build a product that can be used in a multitude of ways without enough thought about how to keep the value secure. I wouldn't even know where to start when deciding whether it's safe to use a smart contract, and I understand the concepts well. If ethereum is ever going to grow into it's current market cap if will have to be safer for use by everybody.