GEMMA Public Blockchain Network
GEMMA Public Blockchain Network
The GEMMA ecosystem will comprise diverse ingenious solutions – such as GEMMA Blockchain, TAG Explorer, Bridges, ZK-Snark, LEMMA Chain, an NFT minting platform, a comprehensive DEFI ecosystem, a decentralized cryptocurrency exchange, and its native GEMMA Token.
Our GEMMA Blockchain will be based on tier-1 which will do Block generation and tier-2 which will do Block Finalization, which will enable the platform to reach the 10,000 TPS (Transactions Per seconds). GEMMA will be public blockchain which will serve as a market for the GEM-20, GEM-1155, GEM-721, GEM-1177, GEM-733 token standards.
While our LEMMA Chain will be created using Hyperledger framework. LEMMA Chain will be parallel processing chain. LEMMA will be a private blockchain which will be used to store private data of the users.
By using ZK-Snark, users are able to choose whether to hide or reveal personal information they submit on the LEMMA Chain. As per the user’s choice while submitting personal data, on the LEMMA Explorer we will replace the user’s hidden information with a hash, using ZK-Snark. Publicly on the LEMMA Explorer users will be able to see only revealed data of other users and the rest of the data will be displayed in the form of hash.
A full node in the diagram below validates blocks and transactions. Most of the full nodes accept blocks and transactions from other full nodes, validate the blocks and transactions, and then further relay them to full nodes. Most full nodes cater to lightweight clients by enabling them to broadcast their transactions on the network and then notifying them as soon as a transaction hit their wallet. Without sufficient nodes performing this function, clients cannot connect via the peer-to-peer network, which means that they will have to rely on a centralized network.
Validator node shown in the below diagram will be a special type of full node that participates in “consensus.” By participating in consensus, validator nodes become responsible for verifying, voting on, and maintaining a record of transactions. Validator nodes underpin the security of GEMMA Blockchain network. That is why it is of vital importance to ensure that validator nodes remain both performant and trustworthy. P0, P1, P2, P3 shown in the below diagram are also resembling the validator nodes. Validator nodes and smart contract will be responsible to process the transactions which will happen via bridge. Nodes will communicate with each other using JSON RPC calls.
The GEMMA Network alleviates barriers to entry and increases accessibility through commission reduction and SDK support. Therefore, it becomes possible for anyone to easily build a secure dApp. This will require technical support to support smart contracts for numerous dApps and GEMMA networks. In line with this, supporting NFT and DEFI is another key element of the GEMMA network. It also includes 21 validator nodes for processing onchain transactions.
GEMMA Node
The nodes in the blockchain are computer networks running the GEMMA Blockchain and are connected to other computers (computers running the same program) around the world.
The GEMMA blockchain node has the following three roles.
Information sharing.
Storing a copy of the confirmed transaction.
Two types of nodes in the GEMMA Blockchain: full node and validator node.
A full node is a node that stores the entire transaction record. It is written to the network server whenever a new block is completed by accessing the blockchain. In other words, since the complete node can read the entire history of the chain transaction, a large network server space is required to maintain the execution state.
The validator node is a full node equipped with the function of verifying new transactions that must be added to the block reflection layer. To this end, there is a private key to sign a valid transaction. They receive a reward (GEMMA token) whenever a new block is created. The entire chain cannot exist without a validator node, and any user can become a validator and be of great help to the decentralized ecosystem of the GEMMA Network.
Node addition leads to the value addition to the network in the following three areas.
The invariant value, more participants will have a copy of the ledger.
The decentralized value allows more stakeholders to participate in governance.
Decentralized value growth, geographical diversity and improved network resilience.
Avoiding Single Point of Failure
A single point of failure (SPOF) occurs when a single entity – either software or hardware – fails in a service, leading to service downtime.
It is impossible to achieve a completely faultless system; faults can happen due to a bug in the code or a problem in hardware such as a router. However, these faults should not cause the entire system to fail.
The problem: The basic architecture of an application comprises a load balancer, app server, cache, and database. When a client makes a request to the load balancer, it points it to the app server. The app server then fetches data from the cache or database and returns a response. This process looks smooth only until all of the components are working. If the database crashes, the service remains down until the database is recovered.
Similarly, the service remains affected if the server crashes. The solution: The problem of SPOF can be avoided by adding a spare for each of the components. When any of the components go down, the spare comes into effect. The spare can be of two types – active and passive. The active components work continuously and distribute the load. On the contrary, the passive components work only when the primary components fail.
Solution implementation: To address the problem of SPOF, GEMMA will add an extra app server. The load balancer will use a round-robin (RR) approach to decide the app server to route the traffic. If one server is down, another will cater to the requests. The app servers will be connected to the primary database, and the secondary database will serve as a spare database. Both databases will be in sync to ensure that if the primary goes down, the secondary takes over.
Furthermore, GEMMA will store data on Google Cloud Platform (GCP), Amazon Web Services (AWS), and Azure in different regions so that if the datacenter that hosts all of the servers goes down due to power failure or any other reason in a region, the application remains up and working.
TPS
TPS is an important factor to discuss when discussing the scalability of a solution. Stable and high TPS can create a foundation for applying blockchain technology to various industries.
Block time refers to the average time it takes to add a new block to the chain. In the case of Bitcoin, it takes about 10 minutes to create a block, and the block size of the chain is 1 MB. Based on this technology, the blockchain in which Bitcoin is operated allows slow 7TPS compared to other cryptocurrencies. In the case of Ethereum, the speed compared to throughput is about 20TPS, triple that of Bitcoin.
The GEMMA blockchain implemented a blockchain capable of up to 10,000 TPS using a multi-tier structure and GPOS consensus algorithm. Specific technical descriptions such as block time and block size will be described in detail in GEMMA YELLOW PAPER v1.0.
Smart Contract
There are basically two types of blockchain-based smart contracts: a blockchain database containing all transaction logs and a database containing the status of smart contracts. Here, the smart contract is an application that can change the state, and the state of the smart contract is a variable used by the application, and the input value to change it is included in the transaction. The smart contract discloses two interfaces: one is transaction and one is query. An interface through a transaction is an approach that is stored in a transaction database and changes the state of a smart contract. Queries are the task of reading the status of smart contracts without being recorded in the transaction database. Transactions execute write, delete, and modify, and queries only execute inquiries through read.
For example, 'product transaction' operates as follows in a smart contract system.
Record storage: A transaction is created by coding the contents of the seller's intention to upload the product and then transmitted to the blockchain. When a product registration transaction occurs, all nodes in the network share the product registration transaction, create a block, and broadcast the block. Each node that receives the block adds the block to the end of its blockchain and applies the transaction stored in the block to synchronize its smart contract database. Through this process, nodes in all blockchain share a smart contract state database.
Product Inquiry: Buyer inquires about products on the blockchain network. Writing to smart contracts generates transactions, but reading already stored values does not generate transactions. Without the need to change any data on the blockchain, only the state values stored in the smart contract database need to be inquired. Therefore, the query information does not need to be synchronized with the blockchain, and may immediately respond regardless of the timing of the block synchronization.
Contract fulfillment: When a buyer sends a purchase transaction, it shares the transaction and synchronizes it to a blockchain network. Product buyers are registered in the smart contract database of all nodes and money is transferred to sellers. The ownership of the registered content is then transferred to the buyer.
As such, since smart contracts share all data with each other, it cannot be manipulated even if a specific user tries to manipulate the execution result of the smart contract. The integrity of smart contracts can also be guaranteed in a way that the blockchain guarantees the integrity of all transactions.
In addition, if the conditions are met, the execution cost of the contract and the possibility of dispute can be reduced by automatically performing the contract. However, in the process of programming a daily language, the cost of the contract creation step may be incurred, and there is a possibility that a programming error problem may occur in this process.
The GEMMA network provides libraries for interfaces between existing systems and smart contracts, such as Ethereum. Like other functions of Ethereum, smart contracts can perform operations such as registering, executing, and inquiring results through existing systems and interfaces such as web servers, mobile, and general PC applications. Languages supported by the official interface library of the GEMMA network include Java, JavaScript, PHP, and Python.
The contact generator is executed off-chain to generate an authentication key and a verification key. In that case, all certifiers can use the certification key to create the certificate off-chain. The general verification algorithm can then be executed within a smart contract using proof, verification key, and public input as input parameters. In the future, other on-chain activities may be triggered using the results of the verification algorithm.
Additionally, the GEMMA network applies random functions to NFT issuance, enabling 100% probability-based minting (to be disclosed on Cryptostone.io). This will lead to the development of decentralized NFT businesses in the future.
Finally, the ZK-Snark algorithm is applied to the smart contract of the GEMMA Network.
The purpose of ZK-Snark is to convince other verifiers or others that they have knowledge of secret parameters known as witnesses that satisfy a relationship without revealing witnesses.
ZK-Snark
ZK-Snark Protocol
ZK-Snark refers to “Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. It is a cryptographic proof that enables one party to prove it owns certain information without revealing that information. This proof is enabled using a secret key that is created before the execution of a transaction.
A ZK-Snark a concept of "zero-knowledge proof." It is a situation in which both the parties in a transaction are able to verify to each other that they possess a particular, while not disclosing the information
For most other types of proofs, either of the two parties must have access to all of the information. A conventional proof can be compared to a password that is used to access an online network. The user enters the password, and the network automatically checks the content of the password to verify that it is correct. To be able to do so, the network must have access to the content of the password.
However, a zero-knowledge proof version of the same situation would work this way. The user would demonstrate to the network, through a mathematical proof, that they have the correct password without actually disclosing the password. It offers the privacy and security advantages in terms of password security. If the network does not have the password stored anywhere for the verification, the password cannot get stolen.
ZK-Snark plays a role in determining whether or not the information to be stored in the transaction is reflected in the GEMMA blockchain. This can contribute to the establishment of a blockchain ecosystem capable of protecting personal information in the future.
ZK-Snark consists of three algorithms G, P, and V defined as follows.
The key generator G generates two public keys, the proof key pk and the verification key vk, by taking the secret parameter 'lamda' and the program C. These keys are public parameters that only need to be generated once for a specific program C.
Prover P takes the prover key pk, public input x and private prover key w as an input parameter. This algorithm creates the proof prf = P(px, x, w) that verifier recognizes the witness w and verified witness satisfies the program.
The verifier V calculates V (vk, x, prf). If the proof is correct, return true, otherwise return false. Therefore, this function returns true if the verifier knows the witness w that satisfies C(x,w) == true.
Here, it is necessary to pay attention to the secret parameter 'lamda' used in the generator. This parameter may make it difficult to use ZK-Snark in real applications. The reason is that anyone who knows this parameter can generate fake evidence. Specifically, a person who knows 'lamda' according to the program C and the public input x may generate a proof fake_prf so that V (vk, x, fake_prf) is evaluated as true without knowing the secret w.
Therefore, in order to actually run the generator, a very secure process is needed to ensure that no one learns and stores parameters. Therefore, as performed in 'Zcash', the GEMMA team performs very sophisticated tasks to generate proof keys and verification keys while reliably destroying the parameter 'lamda'.
GEMMA Explorer
An explorer is a web tool that will utilize API and blockchain nodes to extract data from a blockchain and then utilizes a database to exhibit the data that was searched for and then present it to the user in a searchable format.
It will help users provide comprehensive analytics of the GEMMA Blockchain network from the initial day at the genesis block. It serves as a search engine for the GEMMA Blockchain that allows users to find information about public addresses, individual blocks, and transactions in the GEMMA Blockchain network. In the case of transactions, it can be useful for people waiting for block verification. For example, if the user has a transaction ID for a deposit and withdrawal request on the GEMMA exchange, the flow of funds can be monitored.
In addition, GEMMA Explorer can be the basis for a specific purpose-specific Explorer service. One of them is TAG Explorer for production and inquiry of NFT activation.
Last updated
