TEP: Contract source registry #91
Conversation
talkol
changed the title
|
|
||
| ## sources.json | ||
|
|
||
| JSON file provided by a specific **verifier** for a specific **contract code hash** containing the URLs of source-code files and verification attestations. Fields of this file include: |
There was a problem hiding this comment.
It should also include the original signatures (which are done on the data part of the json)
{
data: {
codeHash:...
},
sigs: [{sig: '...', pubKey: '...'}]
}
otherwise, the UI will not be able to display the signatures used to verify the contract.
There was a problem hiding this comment.
It's indeed nice to add here as well for UI purposes, but then it's a bit circular. Because the signature is over code hash + sources_json_url and the sources_json_url is derived from a hash over its data and the signature is in the data. Do you have any simple way to overcome this?
There was a problem hiding this comment.
What if signatures are stored on chain within the source item contract?
Each signature is 512bit, so this would add another 2-3 cells (assuming 5 verifier multi sig threshold)
This has interesting implications in case we retire and replace one or more of the original verifying nodes, so it would be good to decide how clients should handle such case (i.e. that the public key used to sign can no longer be found in the verifier registry).
|
|
||
| ### Actions | ||
|
|
||
| * `update_verifier(verifier_id, backend_endpoints, quorum_config)` - If the verifier does not exist, ensures it deposits the required amount and adds to the registry. Otherwise updates details in the registry. The address that sends this update message is stored in the registry as the admin address and only it can update. The quorum config contains the list of public keys and how many are needed for quorum. |
There was a problem hiding this comment.
There probably should be a public key (representing the verifier) sent with this op as well, so that future operations (update endpoints, remove verifier) for an existing verifier can be authorized.
There was a problem hiding this comment.
I think the simplest behavior is that the address that sends the update message is regarded as the admin address and only this address can update later. So if the admin is a wallet contract, it would send the internal message of the update and on the first update (insert) it would be set.
There was a problem hiding this comment.
Yes In general I think verifying the sender is more elegant ( and more gas and storage efficient than public key method and simpler to code )
Co-authored-by: Shahar Yakir <[email protected]>
Co-authored-by: Shahar Yakir <[email protected]>
|
|
||
| ## Verifier registry contract | ||
|
|
||
| A smart contract deployed to TON mainnet that holds a mapping between a **verifier id** to the **verifier details** which include the list of backends, their public keys and quorum configuration. To prevent spam in this registry, we propose that each verifier will deposit in the contract a sum of 1,000-10,000 TON coin. This sum will be returned when the verifier unregisters. |
There was a problem hiding this comment.
An interesting point was whether to tie the staking amount to a config param, in order to reflect changes in TON/USD price.
E.g. 10 * 1e9 * Gas price (currently 1,000) => 10K ton
There was a problem hiding this comment.
It's a good idea, since the contract is immutable without any special admin role, this can normalize the deposit size in case TON USD price changes significantly
|
LGFM, maybe just some possible generalizations - we want to have verifiable credentials in ton, and it's verifier is so similar to Verite and may just have the same infrastructure ready and then implement source code repository. |
hacker-volodya
changed the title
Sure, great idea Source code uploaders in the first stage will be through web UI (drag and drop in your browser). We will launch an open source client like jetton.live that runs on GitHub Pages and later offer TF to host it on verifier.ton.org. I think command line tools like toncli and hardhat will come second. Source code verifiers - we are also planning to launch a significant decentralized verifier operated by Orbs Network (orbs.com). It will be executed by a quorum of 21 staked Orbs oracles. Source-code displayers, I think TonWhales explorer is here and I'll contact tonscan.org to join. I already talked about this general concept with them and they're waiting to see the widget that they should embed in their site so they can comment on it |
|
|
||
| #### Actions | ||
|
|
||
| * `update_sources(code_hash, verifier_id, sources_json_url, signatures)` - Verifies that the signatures match the verifier's quorum detailed under **verifier registry** and updates the **sources registry** with the url. |
There was a problem hiding this comment.
The signed data should include a measure of preventing replay attack, such as a valid_until timestamp which can be verified as well.
|
Implementation for the sources registry contract can be found here: |
|
Implementation for the verifier registry contract was carried out via a ton footsteps grant: |
|
Okay
…On Wed, 27 Dec 2023 at 3:34 AM, hebosho911 ***@***.***> wrote:
—
Reply to this email directly, view it on GitHub
<#91 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A73LUSVSHHH2XO26T5M6SBDYLPMRNAVCNFSM6AAAAAAQI6N6AWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZQGA3TGMBYHE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
What do I need to do now
…On Tue, 2 Jan 2024 at 6:37 PM, osas ehimen ***@***.***> wrote:
Okay
On Wed, 27 Dec 2023 at 3:34 AM, hebosho911 ***@***.***>
wrote:
> —
> Reply to this email directly, view it on GitHub
> <#91 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/A73LUSVSHHH2XO26T5M6SBDYLPMRNAVCNFSM6AAAAAAQI6N6AWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZQGA3TGMBYHE>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
|
This comment was marked as spam.
This comment was marked as spam.
2 similar comments
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
There was a problem hiding this comment.
SETCP0
s0 PUSH
IFNOTRET
s0 PUSH
85143 PUSHINT
EQUAL
s1 PUSH
78748 PUSHINT
EQUAL
OR
<{
1 PUSHINT
AND
c4 PUSH
CTOS
32 LDU
32 LDU
s1 POP
256 PLDU
CONDSEL
}> PUSHCONT
IFJMP
INC
32 THROWIF
9 PUSHPOW2
LDSLICEX
s0 PUSH
32 LDU
32 LDU
32 LDU
NOW
s1 s3 XCHG
LEQ
35 THROWIF
c4 PUSH
CTOS
32 LDU
32 LDU
256 LDU
ENDS
s3 s2 XCPU
EQUAL
33 THROWIFNOT
s4 s4 XCPU
EQUAL
34 THROWIFNOT
s0 s4 XCHG
HASHSU
0 5 5 XC2PU
CHKSIGNU
35 THROWIFNOT
ACCEPT
<{
s0 PUSH
SREFS
}> PUSHCONT
<{
8 LDU
LDREF
s0 s2 XCHG
SENDRAWMSG
}> PUSHCONT
WHILE
ENDS
s0 s1 XCHG
INC
NEWC
32 STU
32 STU
256 STU
ENDC
c4 POP
|
UQAoRzwS-wIG-q-99SjdmTMrY9hQC8Kb_IZCxUL8Vmfvx_FS |
|
This proposal defines decentralized infrastructure and an on-chain registry to store the source code for verified TON smart contracts.
The proposal also defines a simple permissionless protocol where community source code verifiers can register and publish signed attestations that they have indeed verified specific contracts.