Open ryanchristo opened 2 years ago
Also relevant to #380.
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?
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
Summary
In the current implementation, when credits are bridged from another chain using
MsgBridgeReceive
, we check the contract provided inOriginTx
and the reference id provided inProject
.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 usingMsgUpdateProjectMetadata
, 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