Realms as EOAs

[leohhhn]

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]

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.

[leohhhn]

To wrap this issue up: a realm is an addressable entity. It can be a User Realm, or a Code Realm. This is reflected in the std package in multiple ways, such as with Test functions or with the Realm.IsUser() funciton.

This will soon be reflected in the upcoming documentation revamp.