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

State Change Receipt Capabilities #18

Closed
kaiyzen opened this Issue Jan 19, 2019 · 4 comments

Comments

Projects
None yet
3 participants
@kaiyzen
Copy link
Collaborator

kaiyzen commented Jan 19, 2019

Certain state changes are invisible and/or time-delayed and not triggered by any immediately observable catalyst:

  • Namespace expiration (triggering a cascade of expiring mosaics)
  • Lock expiration (causing fee payment to harvester or to lock owner)
  • Levy transfers (especially percentage-based levies that require knowledge of current mosaic state)

The primary goal of this feature is to make dependent state changes visible in the block where they take effect.

@kaiyzen kaiyzen added the enhancement label Jan 19, 2019

@kaiyzen kaiyzen added this to the Cow milestone Jan 19, 2019

@gimer

This comment has been minimized.

Copy link
Member

gimer commented Jan 19, 2019

Server part is done, when it comes to namespaces and locks via receipts/statements.
Levy is not there yet and not planned for dragon

@kaiyzen

This comment has been minimized.

Copy link
Collaborator Author

kaiyzen commented Jan 21, 2019

we can break out the levy receipt item into another enhancement and assign to "E" for now, pushing out if needed depending on where scheduling/priorities fall

@Jaguar0625

This comment has been minimized.

Copy link
Member

Jaguar0625 commented Feb 5, 2019

BlockReceiptsHash is set to a non-zero value when a block triggers “invisible” state changes. An invisible state change is any change that is not observable directly from block header and/or transaction data, but, instead, is state-dependent. For example, the changes caused by any transaction referencing aliases is unknowable without knowing the current alias state at the time of execution.

Importantly, receipts allow a client to perform the following so that all state changes are fully explained in a cryptographically secure way:
apply(State(H), Block(H), Receipts(H)) => State(H+1)

Receipts are produced by observers in a deterministic order and hashed into a merkle tree. The merkle tree root hash is stored in the block header.

Catapult can generate three types of receipts:

  1. State Change Receipt: A receipt that informs a client about a state change
    a. Balance Transfer: A mosaic transfer was triggered
    b. Balance Change: A mosaic credit or debit was triggered
    c. Artifact Expiry: An artifact (e.g. namespace) expired
  2. Account Alias: An account alias was used in the block
  3. Mosaic Alias: A mosaic alias was used in the block

Alias receipts record the first occurence of an (unresolved, resolved) alias pair used in a block.

@Jaguar0625

This comment has been minimized.

Copy link
Member

Jaguar0625 commented Feb 8, 2019

@Jaguar0625 Jaguar0625 closed this Feb 8, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment