Updating project and batch metadata via BridgeReceive

[ryanchristo]

Summary

In the current implementation, when credits are bridged from another chain using MsgBridgeReceive, we check the contract provided in OriginTx and the reference id provided in Project.

• If a batch contract mapping exists (within the scope of the credit class), we mint credits to the existing credit batch under the existing project (we do not check reference id because the project id associated with a credit batch never changes).
• If both a batch contract mapping and a project with a matching reference id does not exist (within the scope of the credit class), we create a new project and a new credit batch under the new project.
• If a batch contract mapping does not exist but a project with a matching reference id does exist (within the scope of a credit class), we create a new credit batch under the existing project (and a new batch contract mapping).

When we create a new project and credit batch, we use the metadata provided by the bridge service. When we use an existing project and mint credits to an existing batch, we do not update the metadata.

In the current implementation, project metadata can be updated separate from MsgBridgeReceive by the admin of the project using MsgUpdateProjectMetadata, but batch metadata cannot be updated (intended to be immutable).

Problem Definition

How should we handle updated data on the source chain?

Proposal

[ work in progress ]

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[ryanchristo]

Also relevant to #380.

[pheuberger]

Thank you for writing this @ryanchristo 🙏

A few questions to improve my understanding:

• what is the reference id? as I understand it's not the project id? where is it pointing?
• where is the vintage data stored? entirely in the credit batch?
• where's the batch contract mapping stored? inside the credit batch or somewhere off-chain?

[ryanchristo]

what is the reference id? as I understand it's not the project id? where is it pointing?

The project id on the regen ledger side is an auto-generated project id (e.g. C01-001 is the first project under the C01 credit class, which is also used in batch denoms C01-001-20200101-20210101-001). The project reference id is the project id on the Toucan side, which is also the verra project id (e.g. VCS-001).

We added the reference id when we started working on the bridge service, which allows us to match a Toucan project with a Regen Ledger project. When credits are bridged from Toucan, we search for a project within the credit class with a matching reference id, and if no project is found, we create a new project with the reference id provided.

https://buf.build/regen/regen-ledger/docs/main:regen.ecocredit.v1#regen.ecocredit.v1.Project

where is the vintage data stored? entirely in the credit batch?

A credit batch includes start date, end date, issuance date, and metadata. The metadata field is any arbitrary string but we use the metadata field to store an IRI that points to the data stored off chain.

The bridge service converts the vintage metadata to the schema we use on the registry server and attempts to post the data to the registry server (where the data is being stored off chain), which returns the IRI. We can also generate the IRI without posting the data to the registry server, which we will do after a number of failed attempts and failing to post will trigger an alert letting us know we need to manually post the metadata to the registry server.

https://buf.build/regen/regen-ledger/docs/main:regen.ecocredit.v1#regen.ecocredit.v1.Batch

where's the batch contract mapping stored? inside the credit batch or somewhere off-chain?

The batch contract mapping is stored in a separate table on chain. Since we do not store the credit class key directly within the credit batch and contract is specific to credits being bridged, we decided not to add contract directly to credit batch.

https://buf.build/regen/regen-ledger/docs/main:regen.ecocredit.v1#regen.ecocredit.v1.BatchContract