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.

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

TEP: Contract source registry #91

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

talkol
Copy link

@talkol talkol commented Sep 9, 2022

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.

@talkol talkol changed the title TEP-92: Contract source registry TEP-91: Contract source registry Sep 9, 2022

## 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:

Choose a reason for hiding this comment

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

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.

Copy link
Author

@talkol talkol Sep 9, 2022

Choose a reason for hiding this comment

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

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?

Choose a reason for hiding this comment

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

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.
Copy link

@shaharyakir shaharyakir Sep 9, 2022

Choose a reason for hiding this comment

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

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.

Copy link
Author

Choose a reason for hiding this comment

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

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.

Choose a reason for hiding this comment

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

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 )


## 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.
Copy link

@shaharyakir shaharyakir Sep 11, 2022

Choose a reason for hiding this comment

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

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

Copy link
Author

Choose a reason for hiding this comment

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

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

Choose a reason for hiding this comment

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

Cool

@EmelyanenkoK
Copy link
Member

I think it is expedient to explicitly invite Source-code uploaders(probably tools for deployment like toncli?), Source-code verifiers(currently only tonwhales I believe?) and Source-code displayers (explorer-developers) to discussion.
@tvorogme @ex3ndr @tonscan

@ex3ndr
Copy link

ex3ndr commented Sep 12, 2022

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 hacker-volodya changed the title TEP-91: Contract source registry TEP: Contract source registry Sep 12, 2022
@talkol
Copy link
Author

talkol commented Sep 12, 2022

I think it is expedient to explicitly invite Source-code uploaders(probably tools for deployment like toncli?), Source-code verifiers(currently only tonwhales I believe?) and Source-code displayers (explorer-developers) to discussion. @tvorogme @ex3ndr @tonscan

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.

Choose a reason for hiding this comment

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

The signed data should include a measure of preventing replay attack, such as a valid_until timestamp which can be verified as well.

Copy link

Choose a reason for hiding this comment

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

ادم باش

@shaharyakir
Copy link

shaharyakir commented Oct 11, 2022

Implementation for the sources registry contract can be found here:
https://github.com/ton-defi-org/ton-src-contracts/blob/main/contracts/sources-registry.fc

@shaharyakir
Copy link

shaharyakir commented Oct 11, 2022

Implementation for the verifier registry contract was carried out via a ton footsteps grant:
ton-society/grants-and-bounties#41
and can be found here:
https://github.com/xssnick/registry-contract/blob/master/packages/contracts/sources/registry.fc

@Osasv
Copy link

Osasv commented Jan 2, 2024 via email

@Osasv
Copy link

Osasv commented Jan 2, 2024 via email

@amirbonakchi
Copy link

@Antorhalder

This comment was marked as spam.

2 similar comments
@Antorhalder

This comment was marked as spam.

@Antorhalder

This comment was marked as spam.

Copy link

@Antorhalder Antorhalder left a comment

Choose a reason for hiding this comment

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

UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx

@Antorhalder

This comment was marked as spam.

Copy link

@Danyalkasiri Danyalkasiri left a comment

Choose a reason for hiding this comment

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


Copy link

@Amirshariati Amirshariati left a comment

Choose a reason for hiding this comment

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

Tanks

Copy link

@M-shrahili M-shrahili left a comment

Choose a reason for hiding this comment

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

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

@Madesupra27
Copy link

UQAoRzwS-wIG-q-99SjdmTMrY9hQC8Kb_IZCxUL8Vmfvx_FS

Copy link

@habibhoseiny habibhoseiny left a comment

Choose a reason for hiding this comment

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

منبع قراردادریجستر

@Madesupra27
Copy link

UQAoRzwS-wIG-q-99SjdmTMrY9hQC8Kb_IZCxUL8Vmfvx_FS

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.