Skip to content
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.UpdatedAddresses and “rehearsal mode”, and more #368

Open
dahlia opened this issue Jul 24, 2019 · 3 comments
Open
Assignees

Comments

@dahlia
Copy link
Member

@dahlia dahlia commented Jul 24, 2019

Historically, at the very beginning, we had Transaction.SenderTransaction.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.SignerTransaction.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?

@dahlia dahlia added the suggestion label Jul 24, 2019
@longfin

This comment has been minimized.

Copy link
Member

@longfin longfin commented Jul 24, 2019

That sounds good.

@stale

This comment has been minimized.

Copy link

@stale stale bot commented Oct 30, 2019

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 stale bot added the stale label Oct 30, 2019
@stale stale bot closed this Nov 6, 2019
@limebell limebell reopened this Nov 7, 2019
@stale stale bot removed the stale label Nov 7, 2019
@stale

This comment has been minimized.

Copy link

@stale stale bot commented Jan 6, 2020

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

@stale stale bot added the stale label Jan 6, 2020
@dahlia dahlia removed the stale label Jan 21, 2020
@dahlia dahlia self-assigned this Jan 21, 2020
@dahlia dahlia added the storage label Jan 21, 2020
dahlia added a commit to dahlia/libplanet that referenced this issue Jan 21, 2020
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.
dahlia added a commit to dahlia/libplanet that referenced this issue Jan 22, 2020
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.
dahlia added a commit to dahlia/libplanet that referenced this issue Jan 23, 2020
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.
dahlia added a commit to dahlia/libplanet that referenced this issue Jan 23, 2020
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.
dahlia added a commit to dahlia/libplanet that referenced this issue Jan 23, 2020
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.
dahlia added a commit to dahlia/libplanet that referenced this issue Jan 28, 2020
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.
dahlia added a commit to dahlia/libplanet that referenced this issue Jan 28, 2020
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.