> The Web3 API is the API exposed by the full node themselves, and it exposes the requirement of the ethereum protocol (example: the nonce, the encoding scheme for smart contracts, the primitives operation of the EVM, etc) . It is then wrapped inside libraries in different languages (and you can write your own) but the underlying stuff is constrained by the blockchain protocol itself (you cannot make the nonce mechanism less stupid no matter how hard you try, for instance, the nodes will just reject your transaction if you don't follow the dumb protocol).
Some execution client implementations also expose gRPC and GraphQL APIs, if you would prefer a differentcommunication protocol.
The Web3 APIs are built on top of these underlying APIs exposed by the nodes.
The nonce protocol is indeed rather dumb, but that's not a bad thing, sometimes things need to be specified to be as dumb as they can be. A transaction needs to have a nonce that is greater than the nonce of the last transaction to be included. I think that's pretty much it, if memory serves correct. Obviously nodes will reject transactions that do not meet the rules of the protocol, that's how protocols work.
> Yes, it's the latest hack to have been added to the stack, but it's a hack that obsoleted the former hack, and will end up being obsoleted one day.
EIP-1559 was introduced in 2021. Since then there have been several upgrades, to introduce Proof of Stake and withdrawals. The next upgrade, EIP-4844, will introduce blobspace and will use the same mechanism to price blobspace.
The only changes I have heard on the line regarding this are multi-dimensional EIP-1559 and MEV-burn. These do not alter the principles but keep building on an idea that is working rather well and extends it.
> Except if there's congestion, and the base fee isn't enough so you get your transaction rejected, and you have to guess which base fee to set given that it may have increased once more in the meantime. And so to make sure that your transaction get accepted and does not bounce again, you need to overpay (too bad for a change that was supposed to get rid of overpay…)
> The nonce protocol is indeed rather dumb, but that's not a bad thing, sometimes things need to be specified to be as dumb as they can be.
No, things should get as simple as they can be, the nonce mechanism isn't simple it's dumb: instead of just requiring uniqueness of the nonce, to make sure that there's no duplicate transaction, it attempts to be smart in order to “optimize” the nonce verification cost, and to do so it ads the monotonic increase requirement, and this additional* requirement is bad, because if you try to submit multiple transactions concurrently with the same wallet then you're are almost always going to face issues, with transactions being cancelled because they don't have a valid nonce (it was valid when you submitted it, but now it's not and your transaction is cancelled, sorry not sorry).
The nodes expose the JSON-RPC API, which is specified here: https://ethereum.github.io/execution-apis/api-documentation/
Some execution client implementations also expose gRPC and GraphQL APIs, if you would prefer a differentcommunication protocol.
The Web3 APIs are built on top of these underlying APIs exposed by the nodes.
The nonce protocol is indeed rather dumb, but that's not a bad thing, sometimes things need to be specified to be as dumb as they can be. A transaction needs to have a nonce that is greater than the nonce of the last transaction to be included. I think that's pretty much it, if memory serves correct. Obviously nodes will reject transactions that do not meet the rules of the protocol, that's how protocols work.
> Yes, it's the latest hack to have been added to the stack, but it's a hack that obsoleted the former hack, and will end up being obsoleted one day.
EIP-1559 was introduced in 2021. Since then there have been several upgrades, to introduce Proof of Stake and withdrawals. The next upgrade, EIP-4844, will introduce blobspace and will use the same mechanism to price blobspace.
The only changes I have heard on the line regarding this are multi-dimensional EIP-1559 and MEV-burn. These do not alter the principles but keep building on an idea that is working rather well and extends it.
> Except if there's congestion, and the base fee isn't enough so you get your transaction rejected, and you have to guess which base fee to set given that it may have increased once more in the meantime. And so to make sure that your transaction get accepted and does not bounce again, you need to overpay (too bad for a change that was supposed to get rid of overpay…)
https://arxiv.org/pdf/2201.05574.pdf
EIP-1559 reduced inclusion times and gas fees.