Skip to content

RGB Stock CRDTs #268

Open
Open

Description

@oacdutra

Today the RGB module works based in unit of work concept, or that, each operation can be valid only when everything works, like transaction in database (commit and rollback operations). This approach is a way to prevent inconsistencies in stash.

However, This is not prevent stash inconsistencies in scenarios of the concurrent and/or parallel operations.

For example, Suppose we have a contract with intensive usage and by UX decisions, we allow the users to send and accept transactions Concurrently. One of both operations can be overring the state of the other, causing an inconsistent stash.

We could use a queue to prevent that, but this turns our infrastructure more centralized and also represents a single point of failure.

We can explore a way to turn Stash compatible with the CFDT approach (@cryptoquick's suggestion).

Activity

  1. added this to the 0.8.0 milestone on Jul 13, 2023
  2. self-assigned this
    on Jul 13, 2023
  3. cryptoquick commented on Jul 13, 2023

    @cryptoquick
    Member

    I think CRDTs are the way. It would be great to use something like automerge.

  4. cryptoquick commented on Jul 13, 2023

    @cryptoquick
    Member

    A CRDT solution based on automerge supersedes the solution in #258.

  5. changed the title [-]RGB Stock Resilience[/-] [+]RGB Stock CRDTs[/+] on Jul 19, 2023
  6. modified the milestones: 0.8.0, 0.7.0 on Jul 25, 2023
  7. modified the milestones: 0.7.0, 0.7.1 on Oct 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions