Get rid of `Transaction<T>.UpdatedAddresses` and “rehearsal mode”, and more

[dahlia]

Historically, at the very beginning, we had Transaction.Sender–Transaction.Recipient model, which was made after Bitcoin's or Ethereum's cryptocurrency model. In 0.2 release, we became to need “multiple recipients” because Libplanet is not for cryptocurrencies but games, so we renamed the terminology to Transaction.Signer–Transaction.UpdatedAddresses (#121). However, it's still unhandy to manually specify the list of state addresses that every action in a transaction will mutate, so we had “rehearsal mode” as well in the end (#131), which turns out overkill so that everybody (including me who invented it) dislikes. 🤷🏻‍♂️

In Ethereum, the concept of states are associated with accounts, so keys of the global state map are account addresses. This model works well with the concept of smart contract, which is a kind of accounts hence has an address for each in Ethereum; every smart contract has its own code and state, and there's kind of access control, mutating a contract's state can be done by the code of the same contract (though anyone can read any contract's state). It's basically cryptocurrency and assets, and if you want users to be able to upload some code (i.e., smart contracts), code must not steel others' private assets without owners' authorization.

On the other hand, Libplanet is for games and has no concept of smarts contracts, but follows application-specific blockchain instead. Executed code in the network is part of consensus, and code with no consensus is never executed in the network. Hence we don't need access control unlike Ethereum.

So here's a conclusion: we don't need Transaction.UpdatedAddresses property at all, hance, no “rehearsal mode” either.

Although it's further than the topic, I've recently started to believe keys of the global state map don't have to be (and shouldn't be) addresses, but arbitrary strings instead, which is more easier to understand to existing programmers who are familiar to Redis or memcached.

Any opinions?

[longfin]

That sounds good.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[dahlia]

We will never get rid of Transaction<T>.UpdatedAddresses field, because it already affected already signed transactions. If we remove the field their signatures and IDs would change too.

However, we still can remove the guarantees that each transaction can change only the states listed in its UpdateAddresses at most, (and indeed such guarantee had been silently a dead letter since https://github.com/planetarium/libplanet/pull/1389,) and further get rid of the “rehearsal mode” to automatically list UpdatedAddresses as well.

I'd like to suggest to change the meaning of UpdatedAddresses to the hint for lightweight (dumb) front-ends like Libplanet.Explorer, instead of the strong guarantee.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.