Based on TEP91
The goal is to write a func-based smart contract deployed to TON mainnet which has two responsibilities:
- Maintaining a list of verifiers and their respective verification configuration
- Forwarding arbitrary messages to any contract upon verifying the signature signed by a specified verifier
Verifiers are eligible to forward messages to any contract in the name of the verifier contract, such that downstream contracts can trust any message received by the verifier contract as signed and verified by the specified verifier id.
A mapping between a verifier id to the verifier configuration, which include the list of backends, their public keys and quorum configuration. To prevent spam in this registry, each verifier deposits a sum of 1,000-10,000 TON coin in the contract upon initial registration. This sum will be returned when the verifier unregisters.
To prevent the stored dictionary from being unbounded, there is a 100 verifiers limit.
update_verifier(verifier_id, backend_endpoints, quorum_config)- (internal msg) If the verifier does not exist, ensures the required amount was deposited 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 for this verifier and only it can update. The quorum config contains the list of public keys and how many are needed for quorum.remove_verifier(verifier_id)- (internal msg) Returns the deposited amount and removes the verifier from the registry. Message can only be sent by the original staking address.get_verifier(verifier_id) method_id- Returns details for a given verifier
- Key
verifier_id: uint256// sha256 of verifier name - Value (serialized as cell):
multi_sig_threshold: uint8 - indicates how many signatures are needed in order to forward a message (min: 1)name: bitstring (256): a short human-readable name describing the verifier entityendpoints: a dictionary in the following form:- Key
public key: ED25519 public key - Value: ip address (bitstring)
- Key
forward_message(cell msg)- A message (Forwarded message spec) is received from a 3rd party contract. The verifier id is read from the message and its configuration is loaded. Until multi-sig threshold is reached, each signature is verified. If signatures sent is exhausted without reaching the threshold or a signature mismatch arises, an exception is thrown.
The timestamp is valid for 15 minutes to reduce probability of replay attacks.
Upon verification, the message is forwarded, with the value sent to the message passed on to the next contract (send mode 64).
- A ref containing the forwarded message
- Verifier id (uint256) // sha256 of verifier name
- Timestamp (uint32) // TODO should this be valid until or valid from (+15)
- Msg sender address (message_addr) - the client contract which participated in gathering the signatures. verifying this address as the actual message sender prevents replay of messages within the timestamp interval.
- Contract address to forward to (message_addr)
- A ref containing the arbitrary message forwarded
- A ref containing signatures over the message appearing in the previous ref
- The form is chunked cells: uint512 signature; uint256 pub_key; first 255 bytes of next sig -> ref etc.
- Compiles under func 0.2.0
- Uses latest syntax: consts, include and pragma directives
- Opcodes are CRC32 hashes
- Gas-efficient
- 100% Test coverage (using tvm-contract-executor)
- TL-B schemas for operations and storage
- Github repo with a fully working contract
- update_verifier
- forward_message
- getters
- remove_verifier
- Unit tests
- Full scenario tests
- Sample deploy code
Milestones:
- TL-B + update_verifier method - 25%
- All other deliverables - 75%
Milestones are considered as complete only if delivered in order
- Tying stake amount to config param