I Introduction
1: Overview
Platforms for smart contracts and cryptocurrency, like Ethereum and Bitcoin, have generated a lot of attention and have developed into viable options for decentralized apps, electronic payments, and possible digital value repositories.
But the current situation indicates that the public blockchain iterations on offer have serious limits, especially in terms of scalability, when compared to their centralized equivalents in important metrics. This is impeding their mainstream adoption and postponing public use. In fact, navigating the present engineering constraints imposed by the trade-offs in the blockchain trilemma paradigm has proven to be incredibly difficult. Though many alternatives have been put up, not many have produced noteworthy and workable outcomes.
Therefore, a thorough rethinking of public blockchain infrastructures is necessary to address the scalability issue.
2 Outlining the difficulties
In order to develop a public blockchain system that is scalable, a number of issues need to be adequately addressed:
- Complete decentralization: this removes the possibility of a single point of failure by removing the need for any trusted third parties;
- Strong security: this permits safe transactions and threats attacks based on known attack vectors;
- high scalability: this allows the network to achieve a performance level that is at least equivalent to its centralized counterpart, measured in TPS;
- Efficiency: this performs all network functions with minimal energy and computational requirements;
- Bootstrapping and storage enhancement: this ensures a competitive cost for data storage and synchronization;
- Cross-chain interoperability: this is mandated by design, allowing for unrestricted communication with outside services.
We developed Stake.ch as a comprehensive reimagining of public blockchain infrastructure, with a focus on security, efficiency, scalability, and interoperability, starting from the issues listed above. Stake.ch’s primary contribution is based on two fundamental components:
A true State Sharding method that divides the blockchain and account state into several shards that are managed simultaneously by various validators;
A Secure Proof of Stake consensus mechanism that is an enhanced version of Proof of Stake that guarantees distributed fairness and long-term security without requiring energy-intensive PoW algorithms.
3 Stable Proof of Stake
Expanding on Algorand’s concept of a random selection process, we present a Secure Proof of Stake consensus mechanism that stands out for the reasons listed below:
1)Stake.ch offers an enhancement that lowers latency letting every shard node choose the block proposer and validators for the consensus group at the start of each round. This is made possible by the randomization factor x, which is generated by the block proposer using a BLS signature on the preceding x and saved in each block.
2) The consensus group’s validator with the shortest hash of the public key and randomization factor is the block proposer.
When compared to Algorand’s method, which can take up to 12 seconds for the random committee selection, Stake.ch’s method requires much less time—roughly 70 ms, not counting network latency—for the random selection of the consensus group.
3) Stake.ch improves its consensus mechanism by including an extra weight element called rating in addition to the stake factor that is typically utilized in PoS systems as the only decision input. The likelihood that a node will be chosen for inclusion in the consensus group is based on both rating and stake. The rating of a block proposer is updated at the conclusion of every epoch, with the exception of situations in which rating reductions are necessary. This promotes meritocracy and adds an extra degree of security.
II cDEXgroup ownership
cDEX group is our ownerF in cryptocurrency decentralized exchanges (DEXs) and related blockchain technology.
- There are some key aspects to cDEXgroup partnership:
Trading Pairs: cDEX platforms typically support trading pairs between different cryptocurrencies, allowing users to exchange one digital asset for another.
User Interface and Experience: User-friendly interfaces and intuitive trading experiences are crucial for attracting and retaining users on decentralized exchange platforms.
Security: Security is paramount in the cryptocurrency space. cDEX platform implements robust security measures to protect user funds, prevent unauthorized access, and mitigate potential vulnerabilities.
Token Listings: cDEX platforms may support the listing of various tokens and assets, including mainstream cryptocurrencies as well as newer projects and tokens issued on blockchain networks.
Community and Governance: cDEXgroup incorporate community-driven governance mechanisms that allow users to participate in decision-making processes, such as protocol upgrades, fee structures, and asset listings.
III Arbitrage environment
Arbitrage trading with smart contracts involves leveraging the capabilities of blockchain-based smart contracts to automate and execute arbitrage strategies in decentralized finance (DeFi) ecosystems. Smart contracts are self-executing contracts with the terms of the agreement directly written into code. They run on blockchain networks and automatically enforce the rules and conditions of the contract.
Here’s how arbitrage trading with smart contracts typically works in the context of DeFi:
- Engagement with the established network:
Engagement with an established network to obtain smart contracts for arbitrage trading in DeFi typically involves several steps:
Research and Networking: Developers start by researching and networking within the DeFi community to identify reputable individuals, teams, or organizations that specialize in developing smart contracts for arbitrage trading. This could involve attending blockchain conferences, joining online forums and communities, and networking with experienced professionals in the DeFi space.
Due Diligence: Before engaging with any party to obtain smart contracts, it’s important to conduct due diligence to assess their credibility, track record, expertise, and reputation within the DeFi ecosystem. This may include reviewing past projects, examining code repositories, and seeking references or testimonials from previous clients.
Engagement and Collaboration: Once a suitable partner or development team is identified, traders engage in discussions to outline their specific requirements, objectives, and expectations for the smart contracts. This could involve defining the arbitrage strategies, specifying parameters and conditions, and discussing technical considerations such as security, scalability, and interoperability with existing DeFi protocols.
Contract Negotiation: The network and developers negotiate the terms and conditions of the contract, including pricing, payment terms, delivery timelines, support services, and any other relevant agreements. It’s important to establish clear communication channels and expectations to ensure a smooth and successful collaboration.
Contract Development and Review: The development team proceeds to create, test, and deploy the smart contracts according to the agreed-upon specifications. Developers may have the opportunity to review and provide feedback on the development progress, conduct code audits, and verify the functionality and security of the smart contracts before they are finalized.
Deployment and Integration: Once the smart contracts are completed and thoroughly vetted, they are deployed onto the appropriate blockchain network or platform. Agents work closely with the development team to integrate the smart contracts into their arbitrage infrastructure, connect to relevant DeFi protocols, and ensure seamless execution of arbitrage sessions with the clients that are pre-booked for the deals.
Ongoing Support and Optimization: After deployment, traders may require ongoing support, maintenance, and optimization services incorporating updates or enhancements to adapt to changing market conditions.
By following these steps and engaging with established networks in the DeFi community, developers can obtain high-quality smart contracts for arbitrage trading that align with their objectives and help them capitalize on
IV Dividends arbitrage
Dividend arbitrage is a trading strategy that involves exploiting price differentials between a stock and its associated options or derivatives, particularly around the time when dividends are paid out by the underlying stock.
When used on a security with low volatility (causing lower options premiums) and a high dividend, dividend arbitrage can result in an investor realizing profits while assuming very low to no risk.
Here’s how dividend arbitrage typically works:
- Understanding Dividend Dates:
Companies typically announce dividend payment dates well in advance. These dates include the ex-dividend date (the date after which a buyer of the stock would not receive the upcoming dividend), the record date (the date on which shareholders must be on record to receive the dividend), and the payment date (when the dividend is actually paid out to shareholders).
- Identifying Arbitrage Opportunities:
Dividend arbitrage traders look for discrepancies between the price of the stock and the price of its associated options or derivatives, particularly around the ex-dividend date. They analyze the dividend yield, implied volatility, option prices, and other relevant factors to identify potential arbitrage opportunities.
- Executing the Arbitrage Trade:
When an arbitrage opportunity is identified, agents may take one of several approaches:
Long/Short Stock and Options: They may buy the underlying stock while simultaneously selling call options (covered call) or buying put options (protective put) to hedge their position.
Box Spread: Agents may simultaneously buy a call option and sell a put option at one strike price, while also selling a call option and buying a put option at another strike price, all with the same expiration date. This creates a risk-free arbitrage opportunity if the options are mispriced.
Dividend Capture Strategy: Traders may buy the stock just before the ex-dividend date to capture the dividend, then sell it shortly afterward. They may also simultaneously buy put options to protect against potential downside risk during the holding period.
- Managing Risks:
While dividend arbitrage can be profitable, it also carries risks, including market volatility, changes in dividend policies, and execution risks associated with options trading. Agents implement risk management strategies to mitigate these risks, such as setting stop-loss orders, diversifying their portfolio, and hedging their positions.
Overall, dividend arbitrage is a complex trading strategy that requires a deep understanding of options pricing, dividend policies, and market dynamics. Agents who successfully execute dividend arbitrage strategies can potentially profit from price discrepancies between stocks and their associated options, particularly around dividend payment dates.
How Dividends Are Disbursed
A stock’s ex-dividend date (or ex-date for short), is a key date for determining which shareholders will be entitled to receive the dividend that’s shortly to be paid out. It’s one of four stages involved in dividend disbursal.
Declaration date: The declaration date is the date on which the company announces that it will be issuing a dividend in the future.
Record date: The record date is when the company examines its current list of shareholders to determine who will receive dividends. Only those who are registered as shareholders in the company’s books as of the record date will be entitled to receive dividends.
Ex-dividend date: The ex-dividend date is typically set two business days prior to the record date.
Payable date: The fourth and final stage is the payable date. Also known as the payment date, it marks when the dividend is disbursed to eligible shareholders.
In other words, you have to be a stock’s shareholder of record not only on the record date but actually before it. Only those shareholders who owned their shares at least two full business days before the record date will be entitled to receive the dividend.
V Lending in Defi environment
Lending in decentralized finance (DeFi) refers to the practice of providing or borrowing cryptocurrency assets through decentralized lending platforms, often facilitated by smart contracts on blockchain networks. DeFi lending platforms enable individuals to lend their crypto assets to others in exchange for interest or to borrow assets by providing collateral.
Here’s how lending in DeFi works:
Collateralization: Borrowers on DeFi lending platforms typically provide collateral in the form of cryptocurrency assets to secure their loans. The value of the collateral must exceed the value of the borrowed assets to mitigate the risk of default.
Smart Contracts: Lending and borrowing transactions are executed through smart contracts deployed on blockchain networks such as Ethereum.
These smart contracts automatically enforce the terms and conditions of the loan, including interest rates, repayment schedules, and collateral requirements.
Interest Rates: Interest rates for borrowing and lending are determined by supply and demand dynamics on the lending platform. They may fluctuate based on factors such as market conditions, asset liquidity, and user demand.
Risk Management: Both lenders and borrowers must assess and manage the risks associated with DeFi lending. Lenders face the risk of default by borrowers or smart contract vulnerabilities, while borrowers risk liquidation if the value of their collateral falls below a certain threshold.
Liquidation: If the value of a borrower’s collateral declines significantly, the smart contract may automatically liquidate the collateral to repay the lender and protect against losses.
Liquidation mechanisms vary depending on the lending platform and the specific terms of the loan.
Integration with Other DeFi Protocols:
DeFi lending platforms often integrate with other decentralized finance protocols, such as decentralized exchanges (CDEX) to provide additional liquidity and trading opportunities for users.
Overall, lending in DeFi offers a range of benefits, including accessibility, transparency, and interoperability, compared to traditional centralized lending systems. However, it also comes with risks, including smart contract vulnerabilities, market volatility, and regulatory uncertainties, which users must carefully consider and manage when participating in DeFi lending activities.
VI The built environment Overview.
1.Entities
Stake.ch consists of 3 major entities: network users and nodes.
The Stake.ch network allows users with a limited number of public/private key pairs to deploy signed transactions for value transfers or smart contract execution. Account addresses (derived from public keys) can be used to identify users. The devices in the Stake.ch network, known as nodes, can be either passive or active in processing activities. Validators must actively participate in the Stake.ch network to be eligible. They are responsible for running consensus, adding blocks, maintaining the state, and receiving rewards for their efforts. A public key is used to uniquely identify each validator, a derivation of the staked address and node ID.
Furthermore, the network is divided into smaller parts known as shards. An algorithm assigns an eligible validator to each shard based on the tree level, ensuring fair distribution of nodes. Each shard has a randomly determined consensus group. Block proposers are responsible for aggregating transactions into new blocks. Validators validate and commit proposed blocks to the blockchain. They can reject or approve them.
2. Chronology
The Stake.ch network divides the timeline into epochs and rounds.
Epochs have a defined period of one week, which can be adjusted as the architecture evolves. At the end, the shards are reorganized and pruned. Epochs are organized into rounds, each with a specified timeframe.
Each round, a new consensus group is chosen at random for each shard, with the ability to commit up to one block to the shard ledger.
New validators can join the network by locking in their stakes. They are added to the unassigned node pool in the current epoch and assigned to a shard’s waiting list at the start of the next epoch.
VII Scalability through Adaptive State Sharding
1: Why Sharding?
Sharding is a way of distributing data across numerous devices that originated in databases. This scaling strategy can be used in blockchains to divide states and transaction processing, allowing each node to process only a percentage of transactions concurrently with others. Splitting a blockchain into shards can improve transaction throughput and efficiency by processing multiple transactions in parallel, provided there are enough nodes verifying each transaction for high reliability and security. Sharding, also known as horizontal scalability, increases throughput as the validator network expands.
2: Sharding classifications:
This comprehensive introduction covers three types of sharding: network, transaction, and state sharding. Network sharding groups nodes into shards to enhance communication. Messages can be propagated faster within a shard than across the entire network. The first problem in sharding is ensuring that the system that maps nodes to shards considers potential threats if an attacker obtains control of a specific shard.
Transaction sharding maps transactions to appropriate shards for processing. In an account-based system, transactions may be assigned to specific shards based on the sender’s address.
To boost resilience to malicious attacks, reshuffle nodes in shards periodically. Moving nodes across shards incurs synchronization overheads, which includes the time it takes for newly joined nodes to obtain the latest state. To avoid downtime during synchronization, only a subset of nodes should be redistributed per epoch.
3: Stake.ch sharding methodology:
Stake.ch’s approach to network, transaction, and state sharding aims to achieve the following goals:
1) Scalability without affecting availability: Increasing or decreasing the number of shards should have minimal impact on nodes.
2) Dispatching and instant traceability: Finding the destination shard of a transaction should be deterministic and trivial to calculate, eliminating the need for communication rounds.
3) Efficiency and adaptability: Shards should be as balanced as possible.
The technique Specifications:
To determine the optimal number of shards in epoch ei+1 (Nsh,i+1), we set a threshold coefficient for the number of transactions in a block, θTX. The variable optN determines the ideal number of nodes in a shard, while ϵsh is a positive number indicating the number of nodes that can fluctuate.
In epoch ei, totalNi refers to the total number of nodes on all shards, including eligible validators, waiting lists, and newly added nodes in the node pool. NTXB,i is the average number of transactions in a block across all shards in that epoch. Nsh,0 will be treated as one.
The total number of shards (Nsh,i+1) changes based on the total number of nodes (Ni),if the network changes and blockchain consumption requires it: If the number of nodes exceeds a threshold (nSplit) between epochs and the average number of transactions per block exceeds this threshold.
The function ComputeShardsN determines whether the number of transactions per block (NTXB,i) is more than θTX or whether the number of nodes falls below a certain threshold (nMerge).
The number of active nodes may vary between epochs. To get the number of shards, just calculate the masks m1 and m2, which are utilized for transaction dispatching.
1: function COMPUTEM1ANDM2(Nsh)
2: n ← math.ceil(log2Nsh)
3: m1 ← (1 << n) − 1
4: m2 ← (1 << (n − 1)) – 1
5: return m1, m2
The sharding approach uses a binary tree structure to distribute account addresses, optimize scalability, and handle state transitions. The given tree structure represents the account address space for deterministic mappings, such as shard allocation and sibling computation. The binary tree’s leaves represent shards based on their ID numbers. If there is only one shard/leaf (a) starting from root (node/shard 0), all account addresses are mapped to it, and all transactions are processed there.
1: function COMPUTESHARD(Nsh, addr, m1, m2) 2: shard ← (addr and m1) 3: if shard > Nsh then 4: shard ← (addr and m2) 5: return shard
Root Shard
/ \
Shard A Shard B
/ \ / \
Shard AA Shard AB Shard BA Shard BB
The tree may become unstable (c) if Nsh is not a power of 2. This instance only impacts leaves on the final level. The structure will regain balance when the number of shards reaches a power of 2. The unbalanced binary tree results in shards at the lowest level having half the address space of shards at higher levels. This may result in lesser fee income for active nodes allocated to these shards, but block rewards remain unaffected. To address this issue, a third of shard nodes are randomly reallocated every epoch (see Chronology section) and a balanced distribution of nodes is maintained.
Knowing Nsh allows every node to follow the redistribution process without contact. The allocation of ID’s for the new shards is incremental and reducing the number of shards requires that the higher numbered shards ill be eliminated.
When merging two shards, the highest numbered shard (shmerge=Nsh-1) is deleted. Finding the shard number that shmerge will merge with is simple.
The tree structure assigns the resulting shard the number of its sibling.
1: function COMPUTESIBLING(shmerge, n)
2: sibling ← (shmerge xor (1 << (n − 1)))
3: return sibling
To ensure redundancy, traceability of state transitions, and quick scaling, it’s crucial to identify the sibling and parent of a generic shard with number p:
1: function COMPUTEPARENTSIBLINGS(n, p, Nsh)
2: mask1 ← 1 << (n − 1)
3: mask2 ← 1 << (n − 2)
4: sibling ← (p xor mask1)
5: parent ← min(p, sibling)
6: if sibling ≥ Nsh then
7: sibling ← (p xor mask2)
8: sibling2 ← (sibling xor mask1)
9: parent ← min(p, sibling)
10: if sibling2 ≥ Nsh then ▷ sibling is a shard 11: return parent, sibling, NULL
12: else
13: ▷ sibling is a subtree with
14: ▷ shards (sibling, sibling2)
15: return parent, sibling, sibling2
16: else ▷ sibling is a shard
17: return parent, sibling, NULL
Challenging vulnerability
State sharding on blockchain can fail due to a lack of online nodes or geographically limited distribution. If one shard fails (e.g., all nodes are offline or more than 13 nodes are not responding), the architecture may rely solely on super full nodes to download and verify every block from all shards. Our protocol enforces a tradeoff in state holding structure by requiring shards at the last tree level to hold state from their siblings.
This method eliminates the need for bootstrapping when combining sibling shards, as they already have the necessary data.
Environment Switching
Context switching is critical for ensuring security in sharded public blockchains. Random criteria are used to reallocate active nodes amongst shards at predetermined intervals. Stake.ch’s method improves security through context switching but adds complexity to ensure consistency across different states.
Shard Redundancy Across Epochs
| Epoch 1 | Epoch 2 | Epoch 3 | Epoch 4 |
————————————————————-
Shard 1 | X | X | X | X |
Shard 2 | X | X | X | X |
Shard 3 | X | X | X | X |
Shard 4 | X | X | X | X |
The state shift has a significant impact on performance as it requires resyncing the state, blockchain, and transactions with eligible nodes in the new shard. To maintain liveness at the start of each epoch, less than 1/3 of nodes will be equally distributed between shards.
This method effectively prevents the formation of harmful groups.
Legalization
All network and global data actions (node joining and leaving the network, computation of eligible validator lists, assignment of nodes to shard waiting lists, consensus agreement on a block in a specific shard, and challenges for invalid blocks) will be notarized in the metachain. The metachain consensus is managed by a separate shard that communicates with other shards and enables cross-shard activities. Every round of each epoch, the metachain receives block headers from the other shards, as well as proofs for invalid block challenges. The information will be collected into blocks on the metachain to facilitate consensus. After block validation in the consensus group, shards can securely perform cross-shard transactions by requesting information about blocks, miniblocks, validators, and waiting nodes.
VIII Agreement using SPoS
Bitcoin, Ethereum, and other blockchain platforms use the first blockchain consensus algorithm, PoW. Proof of Work requires each node to solve a mathematical challenge, which is difficult to calculate but trivial to verify. The first node to accomplish the problem will receive the prize . Proof of Work prevents double-spending, DDoS, and Sybil attacks, but requires significant energy usage.
Proof of Stake (PoS) is a more efficient consensus technique compared to Proof of Work, which requires more energy and computational resources. PoS technology can be present in emerging systems such as Cardano [and Algorand , as well as the upcoming Ethereum release. In PoS, nodes suggest the next block based on stake, randomness, and/or age. While it addresses the PoW energy issue, it also raises concerns about the Nothing at Stake attack and increased centralization.
Bitshares , Steemit , and EOS use Delegated Proof of Stake (DPoS), a mix of Proof of Authority and Proof of Stake. Stakeholders elect a small number of nodes responsible for distributing new blocks.
Despite its great throughput, the paradigm is vulnerable to human-related social issues including bribery and corruption.
The small number of delegates makes the system vulnerable to DDoS attacks and centralization.
Partition signing in Stake.ch
Stake.ch leverages curve cryptography for block signing, utilizing the BLS multi-signature scheme over the bn256 bilinear group and the Optimal at Pairing algorithm over a 256-bit Barreto Naehrig curve. Bilinear pairing is defined as e: g0 × g1 → gt (1), where g0, g1, and gt are elliptic curves of prime order p specified by bn256, and e is a pairing function.
Let G0 and G1 be the generators for g0 and g1. Consider H0, a hashing function that generates points on the curve g0: H0: M → g0.
M represents the set of all possible binary messages of any length.Stake.ch signing strategy includes a second hash function with shared parameters across all signers.
H1: M → Zp (3)
Each signer I has a unique private/public key combination (ski, P ki), with ski randomly selected from Zp. For each key pair, the property P ki = ski · G1 applies. In Stake.ch X,
L = P k1, P k2, P kn represents the collection of public keys for all possible signers during a single round. This includes all nodes in the consensus group. The block signing method involves two stages: signature and verification.
In the first round of practical signing. The consensus group leader produces, signs, and broadcasts a block of transactions to its members.
In Round 2, consensus group members (including the leader) validate the block and sign it with BLS before sending it to the leader.
Sigi = ski × H0(m)
Third round of practical signing
The leader waits for signatures within a defined timeframe. The consensus round is aborted if it does not get at least 2·3·n + 1 signatures within the specified timeframe. If the leader receives 2·3·n + 1 valid signatures, these are used to construct the aggregated signature.
SigAgg = X i H1(P ki) · Sigi · B[i].
Practical verification.
The verifier computes the aggregated public key based on the list of public keys L, signer bitmap B, aggregated signature SigAgg, and message m (block). P kAgg = X i · H1(P ki) · Bi (6).
P kAgg represents a point on g1. The final proof is e(G1, SigAgg) == e(P kAgg, H0(m)) (7), where e represents the pairing function.
IX Smart Contracts
Future blockchain architectures rely heavily on smart contract execution. Existing solutions often fail to clearly describe transactions and data dependencies.
This context results in the following two scenarios:
Out of order scheduling can be used in any architecture when smart contract transactions do not have a direct linkage. A smart contract can be performed at any moment and on any shard without further limits.
The second case involves parallel transactions with associated smart contracts . A mechanism is needed to ensure contracts are performed in the correct order and shard.
The Stake.ch protocol offers a mechanism to relocate smart contracts to the same shard as their static. Stake.ch implements the Stake.ch Virtual Machine, an EVM-compliant engine.
The EVM enables independent transaction processing for simple smart contracts that can be run out of order. It also provides a mechanism for connected smart contracts that must be completed sequentially.
Compliance with the Abstraction Layer for Smart Contracts is crucial for acceptance, given the vast number of smart contracts on the Ethereum platform.
The Stake.ch Virtual Machine hides the underlying architecture, separating smart contract developers from system internals and assuring an appropriate abstraction layer dependencies. This ensures that most SC calls have dependencies within the same shard, eliminating the requirement for cross-shard locking and unlocking.
The Stake.ch Virtual Machine solution isolates smart contract developers from system internals, resulting in a good abstraction layer.
Cosmos proposed an adaptor mechanism at the Virtual Machine level in Stake.ch to enable cross-chain compatibility. This technique requires specialized adapters and an external communication medium for each chain to interact with Stake.ch. Specialized smart contracts will act as asset custodians, holding adapted chain native tokens and issuing Stake.ch native tokens to facilitate the value exchange.
Stake.ch virtual machine infrastructure is built on the S Framework, an executable semantic framework that allows for the construction of programming languages, calculi, type systems, and formal analysis tools .
Using the S framework allows for clear definitions of smart contract languages, reducing the possibility of unclear behavior and difficult-to-detect flaws.
The S Framework is executable, allowing semantic specifications to function as functioning interpreters for certain languages. There are two options for running programs against specifications: directly using the S Framework core implementation or creating an interpreter in several languages.
These are also known as “backends”. Stake.ch employs a custom-built S Framework backend for faster execution and easier interoperability.
Smart contract scripts
The S Framework offers the advantage of generating interpreters for any language defined in S without requiring further programming. This process results in “correct-by-construction” interpreters.
Several smart contract languages are either already specified in the K Framework or are being developed. Stake.ch Network supports three low-level languages: IELE VM, KEVM, and WASM.
• IELE VM is a blockchain-specific intermediate-level language modeled after LLVM. The specification and implementation of this feature are exclusive to the S framework and cannot be found elsewhere. The goal is to improve the readability, speed, and overcome limitations of EVMs. Stake.ch differs from IELE mostly in terms of account address management. While smart contract developers can program directly in IELE, most prefer to employ a Solidity to IELE compiler.
• KEVM is a variant of the Ethereum Virtual Machine (EVM) developed in S. The S version addresses some EVM issues, while others are removed entirely.
• Web Assembly (WASM) is a binary instruction format for stack-based virtual machines that can run smart contracts. WASM infrastructure allows developers to construct smart contracts in several languages, including C/C++, Rust, and C#.
Creating a language specification and developing an interpreter is only half the challenge. The remaining portion involves integrating the created interpreter with the Stake.ch network. Our common VM interface allows for easy plug-in of any VM into a Stake.ch node. Each VM has an adapter that implements the interface. Contracts are preserved as bytecode for the VM they were compiled for and executed on that VM.
Smart contracts enabling sharded architecture
Smart contracts built on sharded structures are still in the early phases of development and face significant obstacles. Atomix and S-BAC protocols serve as a starting point.
Moving smart contracts to the same shard does not address dynamic dependencies because not all dependencies can be calculated at deployment time.
A locking technique enables atomic execution of smart contracts across many shards, ensuring that all related SCs are performed simultaneously.
Time or none at all. This involves several interaction messages and synchronization between shard consensuses.
The idea for cross-shard contract yanking in Ethereum 2.0 involves moving smart contract code and data to the caller shard during execution. While atomic execution is not required, the transferred SC must have a locking mechanism in place to prevent further transactions from being executed. The locking technique is simple, but it requires transferring the entire internal state of the SC.
Stake.ch follows Ethereum’s paradigm and offers the following transaction types:
1) SC construction and deployment: transactions receiver address is empty and data field contains the smart contract code as byte array.
2) Invoking the SC method requires a transaction with a non-empty receiver address and accompanying code.
3) Payment transactions require a non-empty receiver and an address with no code.
Stake.ch uses an asynchronous cross-shard execution architecture for smart contracts. The user initiates a smart contract execution transaction.
If the smart contract is not in the current shard, the transaction is treated as a payment transaction. The value is deducted from the sender account and added to the block where the sender shard resides, creating a miniblock with the destination shard where the receiver account is located. The transaction is notarized by metachain and processed by the destination shard. The destination shard treats the transaction as a SC method invocation because the recipient address is a smart contract in the shard.
To invoke the smart contract, a temporary account with the sender’s balance is created and the transaction value is used to call the contract. After execution, the smart contract may produce outcomes that affect many accounts across distinct shards. All results affecting in-shard accounts are executed in the same round. Smart Contract Results transactions are made for accounts that are not in the shard where the smart contract was performed. These transactions save the execution output for each account.
SCR miniblocks are generated for each destination shard. Miniblocks are notarized similarly to cross-shard transactions by the metachain and processed by the corresponding shards where the accounts are stored.
If a smart contract makes a dynamic call to another shard, the call is recorded as an intermediate result and treated similarly to accounts.
The method involves numerous stages and at least 5 rounds to complete a cross-shard smart contract call. However, there is no need for locking or state movement across shards.
Epochs
The Stake.ch Protocol sets a fixed period of 7 days for each epoch, which may change after many tested confirmation phases. During this interval, the shard configuration remains constant.
The system adjusts the number of shards based on epoch-specific scalability demands. To prevent collusion, each shard’s configuration should change after each epoch. Although reshuffling all nodes across shards increases security, it also introduces additional delay due to bootstrapping.
At the end of each epoch, less than 1/2 of qualified validators from a shard are transferred to other shards’ waiting lists in a non-deterministic and consistent manner.
The node shuffling process involves several steps:
- New nodes registered during the current epoch will remain in the unassigned node pool until the end of the epoch.
- Less than 1/2 of nodes in each shard are randomly reshuffled and added to the designated node pool.
- The new number of shards (Nsh,x+1) is calculated depending on network node count (ki) and use.
- Synchronized nodes from all shard waiting lists are added to the eligible validator’s list.
- During epoch xi+1, newly added nodes from the unassigned node pool are distributed uniformly across all shards’ waiting lists.
- In the following epoch xi+2, reshuffled nodes from the assigned node pool are redistributed with higher ratios to shards’ waiting lists that will need to be split.
Each round lasts 5 seconds. Updates may occur after multiple testnet confirmation phases. Each round, a randomly selected set of block validators (including one proposer) create a new block within each shard. The eligible nodes list is used to update the set between rounds, as described in Chapter IV.
The reconfiguration of shards within epochs and arbitrary selection of validators inside rounds prevents unfair coalitions, reduces DDoS and bribery attempts, and maintains decentralization and high transaction throughput.
Randomness source
Stake.ch uses random numbers for operations such as selecting block proposers and validators for consensus groups and shuffling nodes between shards at the end of an epoch. These elements strengthen Stake.ch’s security guarantees.
To ensure accuracy, random numbers should be proven to be unbiased and unpredictable. Random number generation must be efficient and scalable for usage in high-throughput blockchain architectures.
Some asymmetric cryptography techniques, including the BLS signature scheme, have these qualities. BLS ensures that using the same private key to sign a message yields consistent results. This is comparable to the results of ECDSA with deterministic k generation, as the technique does not use random parameters.
Node Rating
The rating of an eligible validator affects their chances of being picked for the consensus group, in addition to stake. If a block proposer is honest and their block is committed to the blockchain, their rating will climb. Otherwise, it will decrease. This encourages validators to be honest, use the latest client software, and boost service availability, ensuring the network runs properly.
Redundancy between shards
Nodes deployed in sibling shards at the lowest level of the tree communicate with one another to share blockchain data and application state. Implementing shard redundancy allows for the merging of sibling shards as the network’s node count falls. Targeted nodes will immediately begin shard merging.
X Centralized vs Decentralized
Centralized systems have a single point of control, while decentralized systems distribute control across a network of participants.
Blockchain was developed to replace centralized financial systems. While distributed systems offer freedom and anonymity, their performance must be evaluated globally in real-world scenarios.
The most significant statistic for measuring performance is transactions per second (TPS).
A comparison of traditional centralized systems against decentralized designs proven for trust and efficiency on a broad scale reveals an objective but uncomfortable fact.
Blockchain architecture scalability is a significant issue that has yet to be addressed.
Consider the impact on data storage and bootstrapping if existing blockchain designs achieve Visa-level throughput.
These exercises highlight the extent of several secondary difficulties.
Blockchain Performance Framework
Designing distributed systems on blockchain has problems, including maintaining operability under strain. The key factors that impact performance pressure are:
• Complexity
• System size
• Transaction volume.
Performance
Performance testing and simulations demonstrate the solution’s efficiency as a highly scalable distributed ledger. Our sharding strategy leads to a linear increase in throughput as more nodes join the network.
The consensus model’s several communication rounds rely heavily on network quality (speed, latency, and availability). Simulations on our testnet using global network speed averages show that Stake.ch can surpass the average Visa level with only 2 shards and reach the peak VISA level with 16 shards.
Current and future study research
Stake.ch is a public blockchain architecture that combines scalability through adaptive state sharding, security, and energy efficiency through a secure Proof of Stake consensus mechanism. Our team is constantly evaluating and improving its design to make it more appealing.
Our future improvement goals include:
2) AI supervision: Create an AI supervisor to detect dangerous behavior patterns. It is unclear how to implement this functionality into the protocol without damaging decentralization.
3) Adding reliability as a consensus factor: The current system prioritizes stake and rating, but we propose incorporating reliability as a distributed metric after applying a consensus procedure on previously submitted blocks from recent history.
4) Promote cross-chain interoperability by implementing and contributing to standards developed by the Decentralized Identity Foundation and the Blockchain Interoperability Alliance .
5) For privacy-preserving transactions, employ Zero-Knowledge Succinct Non-Interactive Argument of Knowledge, which protects participants’ identities and provides auditing possibilities.