The SGE Network chain relies on external off-chain data of matches and other markets. To push this data reliably to the chain, some kind of origin verification is required. The OVM module essentially fills this role in the SGE Network chain. The OVM Module verifies the following data:
Event data pushed by the House to the chain.
Validity of Odds data during bet placement by the bettor.
To verify the origin of the data, a simple mechanism of signing and verification with a private key and the corresponding public key is performed.
The data that needs to be pushed into the blockchain is first signed by the private key of a trusted source. This process occurs off-chain. Essentially, we create an encrypted ticket with the trusted private key. The curve used for signing and verification of the ticket is the Edwards-curve Digital Signature Algorithm. This algorithm has been chosen for the following benefits:
Fast single-signature verification
Fast batch verification
Very fast signing Fast key generation
High-security level
Foolproof session keys
Collision resilience
No secret array indices
No secret branch conditions
Small signatures
Small keys
Details of the algorithm can be found here.
After generating the encrypted signed ticket
, this signature data is included in the transactions. This includes transactions for adding/editing betting markets on the chain, as well as verifying odds when the user places on these markets. All tickets come with an expiry timestamp which invalidates the ticket after a certain duration. This facility prevents the use or abuse of old and expired tickets.
The OVM Module
essentially stores a list of trusted public keys. These public keys are just the counterpart to the private keys that were used to sign and encrypt the tickets off-chain. When a transaction is made to the chain that necessitates verification of the origin of the data, the corresponding module invokes the OVM module for verification and decryption purpose. The OVM Module works as an interface, which can decode any signed data passed to it when supplied with the encryption algorithm and the decrypted type. This design completely nullifies the need to change the structure of the OVM if the ticket structure changes. This essentially enables the OVM to be a global verification module.
When the OVM is invoked, it first attempts to verify the signature of the data against the list of registered public keys. If the signature is verified successfully by the leader public key (the first element in the public keys slice in the key vault store), the OVM decrypts the data into the provided structure and returns it to the invoking module. In case the signature verification fails, or the ticket seems to have expired, or the decrypted structure does not match with the expected structure, the verification is considered to be a failure and a corresponding error is returned to the invoking module, which consequently results in failure of the transaction.
The OVM Leader is the public key that is being used for the verification of the tickets, The first element of the Key Vault public keys is the leader. If the private key of the leader's public key gets corrupt/hacked/leaked, The holders of the rest of the public keys can create a pub keys-change proposal to replace the leaked public key with a new one and choose the new leader key. Each proposal needs at least 3 "yes" or 2 "no" to make blockchain code to decide about the proposal's approval or rejection, the modification happens in the end blocker if the condition of votes is satisfied.
Origin Verification Module
The Origin Verification Mechanism (OVM) is used to verify the origin of any off-chain data when they are pushed into the chain. This module ensures that no corrupt or unauthenticated data can make its way into the chain.
The OVM module has only one state table consisting of a list of strings that are the trusted public keys.
The Public Keys is an entity that stores the public keys of the registered oracles which can verifiably push data to the blockchain. It contains:
public_keys
: A list of allowed public keys.
The proto for the PublicKeys is as follows:
The public keys change proposal is store in the state to be used to change the compromised public keys.
The vote tracks the votes for the proposals.
The proposal statistics are stored to keep track of the count of proposals.
OVM module CLI.
This section specifies the queries, transactions, and required payloads. By following this section, one can get a deep understanding of the functioning of the ovm
module in the SGE Network chain.
The exposed transactions CLI commands and ticket payloads by the OVM module.
The below transaction can be used to create a proposal for pubkey change on the blockchain.
The below table specifies the details of the arguments used in the above transaction:
The payload for the proposal transaction is as follows:
The below transaction can be used to create a proposal for pubkey change on the blockchain.
The below table specifies the details of the arguments used in the above transaction:
The payload for the vote transaction is as follows:
Argument | Description | Type | Validation | Example |
---|---|---|---|---|
Argument | Description | Type | Validation | Example |
---|---|---|---|---|
Params | Description | Type | Validation | Example |
---|---|---|---|---|
ticket
Used for proposal verification.
String (JWT token)
Cannot be empty
Cannot contain space (More validations will be added in the future)
1eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOiI5OTkxYzYwZi0yMDI1LTQ4Y2UtYWU3OS0xZGMxMTBmMTY5OTkiLCJ4aWQiOiJCZXRPZGQiLCJuYW1lIjoiMSIsImJldF9ldmVudF91aWQiOiI1NTMxYzYwZi0y
MDI1
ticket
Used for proposal verification.
String (JWT token)
Cannot be empty
Cannot contain space (More validations will be added in the future)
1eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOiI5OTkxYzYwZi0yMDI1LTQ4Y2UtYWU3OS0xZGMxMTBmMTY5OTkiLCJ4aWQiOiJCZXRPZGQiLCJuYW1lIjoiMSIsImJldF9ldmVudF91aWQiOiI1NTMxYzYwZi0yMDI1
pubkeyIndex
The registered pubkey index that you are voting on behalf
uint32
Cannot be empty
The pubkey index should be available in current public keys list
The ticket should be signed with the private key corresponding to this pubkey at index
1
status
Active or finished proposals
uint32
Required
1 or 2
1: Active 2: Finished