-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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"
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 |
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.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 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.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?
The text was updated successfully, but these errors were encountered: