Get rid of Transaction<T>.UpdatedAddresses and “rehearsal mode”, and more
#368
Comments
|
That sounds good. |
|
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. |
|
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions. |
It's the first step to refer to states by arbitrary string keys instead of Addresses, as I suggested in the issue: planetarium#368 > 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.
It's the first step to refer to states by arbitrary string keys instead of Addresses, as I suggested in the issue: planetarium#368 > 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.
It's the first step to refer to states by arbitrary string keys instead of Addresses, as I suggested in the issue: planetarium#368 > 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.
It's the first step to refer to states by arbitrary string keys instead of Addresses, as I suggested in the issue: planetarium#368 > 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.
It's the first step to refer to states by arbitrary string keys instead of Addresses, as I suggested in the issue: planetarium#368 > 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.
It's the first step to refer to states by arbitrary string keys instead of Addresses, as I suggested in the issue: planetarium#368 > 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.
It's the first step to refer to states by arbitrary string keys instead of Addresses, as I suggested in the issue: planetarium#368 > 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.
|
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions. |
|
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions. |
…ndition Revert "hotfix: condition"
dahlia
changed the title
Transaction.UpdatedAddresses and “rehearsal mode”, and more
|
We will never get rid of However, we still can remove the guarantees that each transaction can change only the states listed in its I'd like to suggest to change the meaning of |
dahlia
changed the title
Transaction.UpdatedAddresses and “rehearsal mode”, and moreTransaction<T>.UpdatedAddresses and “rehearsal mode”, and more
|
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions. |
Historically, at the very beginning, we had
Transaction.Sender–Transaction.Recipientmodel, 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 toTransaction.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.UpdatedAddressesproperty 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?
The text was updated successfully, but these errors were encountered: