4 ms·

Could you provide examples of previously deployed dirty hacks that need more dirty hacks to circumvent the flaws?

by pa7x1 3y ago

littlestymaar 3y ago
Well, the entirety of the “Web3” API is a pile of hacks, but my “favorite” is probably eip-1559 (and not for the “political” reasons, like “make eth deflationary”, it's just very annoying to work with).
- pa7x1 3y ago
  This is like complaining about the HTTP protocol because you don't like the requests Python library. There is no "Web3" API as part of the Ethereum protocol. "Web3" APIs (in plural because there are multiple ones, in different programming languages) are externally built libraries that expose in an API details about the Ethereum blockchain (blocks, transactions, gas consumed in a block, base fee, etc...). If you don't like a particular library, you can use a different one, or build your own. EIP-1559 has never been patched. It's still functioning as it was conceived. A minor clarification is that it was not introduced to make ETH deflationary, and in fact, it doesn't guarantee in any way that it will be deflationary. It's a side effect of demand for settling on Ethereum exceeding the current issuance of ETH. In much the same way the supply of oil may go down if demand for it is greater than its production. In what ways is it annoying to work with EIP-1559? It's, I would argue, much simpler than it was in the past, as you now have a pre-defined base fee to pay to be included in a block. But perhaps you have something else in mind.
  - littlestymaar 3y ago
    > This is like complaining about the HTTP protocol because you don't like the requests Python library. There is no "Web3" API as part of the Ethereum protocol. "Web3" APIs (in plural because there are multiple ones, in different programming languages) are externally built libraries that expose in an API details about the Ethereum blockchain (blocks, transactions, gas consumed in a block, base fee, etc...). If you don't like a particular library, you can use a different one, or build your own. 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). > EIP-1559 has never been patched. It's still functioning as it was conceived. 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. > In what ways is it annoying to work with EIP-1559? It's, I would argue, much simpler than it was in the past, as you now have a pre-defined base fee to pay to be included in a block. 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…) Many things in Ethereum stops working well as soon as you leave the full node itself and develop a third party service relying on its RPC endpoint (which is nonetheless the mainstream way to do it).
    - latchkey 3y ago
      > the nodes will just reject your transaction if you don't follow the dumb protocol Calling things dumb doesn't help your argument at all. It should reject your transaction if you don't follow the rules. > Except if there's congestion, and the base fee isn't enough so you get your transaction rejected Subtle, but important point: The transaction isn't rejected. It is not picked up out of the mempool and sits there until the congestion goes down. Again, this is supply/demand pricing and that's ok in a system like this. > Many things in Ethereum stops working well This is handwaving without actual examples.
      - littlestymaar 3y ago
        > Subtle, but important point: The transaction isn't rejected. It is not picked up out of the mempool and sits there until the congestion goes down. Not if you submit another transaction in the meantime, because then your initial transaction's nonce will have become invalid. Now you start to get why I called the nonce system “dumb”, because it has emergent implications with lots of things like this, for no good reason (the requirement should be nonce's uniqueness, that's enough for transaction deduplication, but they felt smart and added the “monotonically increasing” as well, and boom, concurrent transaction processing is a nightmare now, well done).
    - pa7x1 3y ago
      > 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). The nodes expose the JSON-RPC API, which is specified here: https://ethereum.github.io/execution-apis/api-documentation/ 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 https://arxiv.org/pdf/2201.05574.pdf EIP-1559 reduced inclusion times and gas fees.

Could you provide examples of previously deployed dirty hacks that need more dirty hacks to circumvent the flaws?

by pa7x1 3y ago

Could you provide examples of previously deployed dirty hacks that need more dirty hacks to circumvent the flaws?

Well, the entirety of the “Web3” API is a pile of hacks, but my “favorite” is probably eip-1559 (and not for the “political” reasons, like “make eth deflationary”, it's just very annoying to work with).

pa7x1 3y ago
This is like complaining about the HTTP protocol because you don't like the requests Python library. There is no "Web3" API as part of the Ethereum protocol. "Web3" APIs (in plural because there are multiple ones, in different programming languages) are externally built libraries that expose in an API details about the Ethereum blockchain (blocks, transactions, gas consumed in a block, base fee, etc...). If you don't like a particular library, you can use a different one, or build your own. EIP-1559 has never been patched. It's still functioning as it was conceived. A minor clarification is that it was not introduced to make ETH deflationary, and in fact, it doesn't guarantee in any way that it will be deflationary. It's a side effect of demand for settling on Ethereum exceeding the current issuance of ETH. In much the same way the supply of oil may go down if demand for it is greater than its production. In what ways is it annoying to work with EIP-1559? It's, I would argue, much simpler than it was in the past, as you now have a pre-defined base fee to pay to be included in a block. But perhaps you have something else in mind.
- littlestymaar 3y ago
  > This is like complaining about the HTTP protocol because you don't like the requests Python library. There is no "Web3" API as part of the Ethereum protocol. "Web3" APIs (in plural because there are multiple ones, in different programming languages) are externally built libraries that expose in an API details about the Ethereum blockchain (blocks, transactions, gas consumed in a block, base fee, etc...). If you don't like a particular library, you can use a different one, or build your own. 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). > EIP-1559 has never been patched. It's still functioning as it was conceived. 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. > In what ways is it annoying to work with EIP-1559? It's, I would argue, much simpler than it was in the past, as you now have a pre-defined base fee to pay to be included in a block. 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…) Many things in Ethereum stops working well as soon as you leave the full node itself and develop a third party service relying on its RPC endpoint (which is nonetheless the mainstream way to do it).
  - latchkey 3y ago
    > the nodes will just reject your transaction if you don't follow the dumb protocol Calling things dumb doesn't help your argument at all. It should reject your transaction if you don't follow the rules. > Except if there's congestion, and the base fee isn't enough so you get your transaction rejected Subtle, but important point: The transaction isn't rejected. It is not picked up out of the mempool and sits there until the congestion goes down. Again, this is supply/demand pricing and that's ok in a system like this. > Many things in Ethereum stops working well This is handwaving without actual examples.
    - littlestymaar 3y ago
      > Subtle, but important point: The transaction isn't rejected. It is not picked up out of the mempool and sits there until the congestion goes down. Not if you submit another transaction in the meantime, because then your initial transaction's nonce will have become invalid. Now you start to get why I called the nonce system “dumb”, because it has emergent implications with lots of things like this, for no good reason (the requirement should be nonce's uniqueness, that's enough for transaction deduplication, but they felt smart and added the “monotonically increasing” as well, and boom, concurrent transaction processing is a nightmare now, well done).
  - pa7x1 3y ago
    > 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). The nodes expose the JSON-RPC API, which is specified here: https://ethereum.github.io/execution-apis/api-documentation/ 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 https://arxiv.org/pdf/2201.05574.pdf EIP-1559 reduced inclusion times and gas fees.