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

Realms as EOAs #1579

Open
leohhhn opened this issue Jan 24, 2024 · 1 comment · May be fixed by #1469
Open

Realms as EOAs #1579

leohhhn opened this issue Jan 24, 2024 · 1 comment · May be fixed by #1469
Assignees

Comments

@leohhhn
Copy link
Contributor

leohhhn commented Jan 24, 2024

In order to write unambiguous documentation, I would like to better understand the reason behind why we say that Realms can also be users. What is the idea behind making this connection, and how can we disambiguate it?

In most of our docs, Realms are simply smart contracts written in Gno. However, in some cases, like when trying to explain that PrevRealm() can return the following in case the previous caller was an EOA:

Realm {
    pkgPath: "",
    addr: "g1......"
}

Or when explaining the Realm.IsUser() function, more clarification on this topic would be very needed.

It seems to me that I am missing what the concept of Realms in Gno really means.

@moul
Copy link
Member

moul commented Jan 26, 2024

I understand that it's challenging to explain, so let's delve into more specifics:

The realm should not be viewed merely as a "code package." Rather, it's more accurately an addressable entity (with a std.Address format) that can be part of the caller stack. This includes being the direct caller, having the ability to send and receive native coins, and possessing other grcXXX assets.

Commonalities between a code realm and a user realm include:

  • Being addressable with std.Address.
  • The capability to own, receive, and send native coins, facilitated by the banker module.
  • The potential to be used for ACL/ownership by looking at PrevRealm() (grcXXX).
  • The ability to be the direct caller in your code realm.

However, they differ in several ways:

  • You can't perform a "maketx call" on a user realm.
  • A user realm lacks its own code but can create volatile contracts with a fixed address via maketx run.
  • A contract realm cannot exist as an EOA on the main chain.
  • A contract realm might eventually be regarded as an EOA through IBC, though I'm still contemplating this idea. It seems logical that events queued for IBC transmission could be treated as EOAs when processed through IBC relayers.
  • Currently, only the code realm possesses variables/states, unlike the user realm. I'm considering how to potentially integrate this feature meaningfully.

To draw a parallel with Ethereum, both a user and a contract, identified by their 0xabcdef keys, can own assets or execute calls. Although they don't use the term "realm," there exists a similar concept where a single term is needed to refer to the caller, which could be a vault contract, a DAO contract, a wallet, or a multisig.

Thank you, Leon, for addressing this question. I'll continue to ponder if there are additional aspects to include.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Awaiting/Blocked
Status: No status
Development

Successfully merging a pull request may close this issue.

2 participants