Skip to content
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.

Sign up for GitHub

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

Jump to bottom

doc: Off chain contract registry #6

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

doc: Off chain contract registry #6

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions in-progress/NNNN-off-chain-contract-registry.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
| | |
| -------------------- | --------------------------- |
| Issue | Off-chain contract registry |
| Owners | @spalladino |
| Approvers | |
| Target Approval Date | |

## Executive Summary

Since private contracts are not broadcasted on-chain, they need to be registered in a PXE before they can be executed. We expect this to be typically done by the dapp in context, but for composability's sake and ease of development, especially during devnet, we could make things easier by keeping a canonical off-chain registry of contracts.

## Introduction

When executing a private function on a contract in the PXE, we require that the corresponding contract instance and artifact to have been registered in advance.

We can extend the PXE to fall back to requesting the instance and artifact to an external provider, and registering them on the fly during a simulation. Since the contract address acts as a commitment to the instance and artifact, the PXE can validate the downloaded artifact against the address itself by recomputing the class id and instance address.

## Interface

We split the interface into two: one for uploading and registering instances and artifacts, and another for querying. This allows us to implement a trusted registry with just the query interface first, to make it quickly available to devs, and manage the registration centrally until we implement the more complex uploading API.

### Querying

#### GET `/contracts/{address}.json`

Returns the JSON-serialized contract instance for the given address, which includes the class identifier.
Copy link
Contributor

@PhilWindle PhilWindle Jul 4, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remind me again what would go in here? Is it simply the class id, the initialisation args/hash, deployer address etc?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly!

salt
deployer
contractClassId
initializationHash
publicKeysHash


#### GET `/artifacts/{class_id}.json`

Returns the JSON-serialized contract artifact (as generated by Nargo) for the given class identifier.

### Uploading

#### POST `/contracts/{address}.json`

Uploads a JSON-serialized contract instance for the given address. The server must verify that the instance hashes to the given address.

#### POST `/artifacts/{class_id}.json`

Uploads a JSON-serialized artifact for the given class id. The server must verify that the artifact hashes to the given class id.

## Implementation Notes

The flat querying API means we can implement the registry in a plain file storage service like S3.