TXO + STXO vs UTXO Re: Original Vision



Summary:

In a discussion, Mark Friedenbach explains that the slow down factor of TXO/STXO trees has to do with the depth of the tree and they are always growing. However, these trees can be pruned. While it's not necessary to have constant time updates, there are alternatives like updating the TXO tree and requiring blocks and transactions to carry proofs with them. This pushes the problem to whoever generated or assembled the proof. The proposal is useful for building UTXO at any height from committed txo + stxo trees and updating it yourself from there. For the SPV use case, you would need a committed UTXO but that could be done separately later. Committing validator state in each block would require maintaining a hash tree commitment over validator state which is insanely expensive. With the UTXO commitment scheme, this ends up requiring 15-22x more I/O during block validation leading to slower validation speed. Therefore, if one wants this commitment scheme for fraud proofs, they should be arguing for a block size limit decrease (to 500kB), not an increase. A proposal for a TXO and STXO O(1)-append commitment is also presented, which shouldn't cause much overhead and can build UTXO from TXO-STXO.


Updated on: 2023-06-10T01:38:19.557552+00:00