Developers Forum for XinFin XDC Network: Galaxy

[Proposal] Adding an isOwner Function to the Validator Smart Contract

Galaxy — Mon, 06 May 2024 11:56:53 +0000

Purpose:

The isOwner function provides a way to verify if a specific address corresponds to the owner of the validator smart contract. This functionality can be useful in various scenarios, such as:

Restricting access to certain administrative functions within the contract.
Granting voting rights or other privileges only to the owner.

Implementation Details:

isOwner Function:
- Define a public function named isOwner that takes an address argument (owner).
- Inside the function, compare the provided address (owner) with the stored owner address (owner).
- Return true if they match, indicating the address is the owner. Otherwise, return false.

Solidity Code Example:

    // isOwner : check if the given address is an owner or not.
    function isOwner(address owner) public view returns (bool) {
        for (uint i = 0; i < owners.length; i++) {
            if (owners[i] == owner) {
                return true;
            }
        }
        return false;
    }

Benefits:

Improved security by restricting access to sensitive functionalities.
Increased flexibility in managing validator permissions.
Enhanced transparency by allowing users to verify ownership.

Tips:
This is from @0xbeny idea, I just help him to improve the code

[Informative] Subswap aggregator module draft : Next generation deal aggregator

Galaxy — Sat, 13 Apr 2024 05:16:02 +0000

Subswap Aggregator on XDC: Current State, Problems, Solutions, and Advantages

1. Problems statement

Currently, there are multiple DEXs on the XDC Network, each with its own liquidity pool and trading pairs. This leads to the problems of fragmented liquidity and price discrepancies.

Fragmented liquidity and price discrepancies lead to the following problems:

Users have difficulty finding the best trading price
Increased transaction slippage
Slower transaction execution speed

2. Solution : deal aggregator

A Subswap aggregator can solve the above problems. The aggregator provides users with the best trading price and the most optimized transaction execution plan by aggregating the liquidity pools and trading prices of multiple DEXs.

Subswap aggregator provides users with the following advantages:

Better trading prices: Users can find the best-priced solution by exploring all possible trading options through the aggregator.
Lower transaction slippage: The aggregator can help users reduce transaction slippage, thereby lowering transaction costs.
Faster transaction speed: The aggregator can optimize the transaction execution path, thereby improving transaction speed.
Higher liquidity: The aggregator can aggregate the liquidity of multiple DEXs, thereby providing users with greater liquidity.

3. How does it works

The aggregator collects liquidity pool and trading price data from multiple DEXs
Based on the user's trading request, the aggregator calculates all possible trading solutions
Selects the trading solution with the best price, the least slippage, and the fastest execution speed
Sends the trading instruction to the selected DEX for execution

This is a picture of the UI of the okx aggregator

It can be very intuitive and simple to trade the tokens you own, and link multiple swap protocols on the chain.

This is a picture of the UI of the binance aggregator

It can use tokens from any chain to exchange for different tokens on different chains.

4. Tentative Proposal

To actualize the Subswap aggregator on the XDC Network, we need a cohesive plan encompassing development, marketing, and operations. Here's a preliminary proposal outlining the key components and a six-month development timeline:

Development Phase (6-12 months)

Research and Analysis: Conduct an in-depth analysis of existing DEXs on the XDC Network, their liquidity pools, trading pairs, and APIs for data collection.
Prototype Development: Build a prototype of the Subswap aggregator platform that can collect data from multiple DEXs, perform price calculations, and generate optimized trading solutions.
Smart Contract Development: Develop smart contracts for executing trades on selected DEXs securely and efficiently.
User Interface Design: Design an intuitive and user-friendly interface for the Subswap aggregator platform, ensuring seamless navigation and accessibility for both novice and experienced traders.
Testing and Optimization: Conduct extensive testing to ensure the reliability, security, and efficiency of the aggregator platform. Optimize algorithms for price calculation, trade execution, and data synchronization.
Integration and Deployment: Integrate the developed components into a cohesive platform and deploy it on the XDC Network. Ensure compatibility with various wallets and trading interfaces.

These numbers are indicative, and the specific personnel requirements should be adjusted and optimized based on the project's specifics and the team's capabilities.

By following this comprehensive plan, we aim to successfully develop, launch, and promote the Subswap aggregator on the XDC Network, providing users with superior trading experiences and contributing to the growth and development of the decentralized finance (DeFi) ecosystem on XDC.

[Proposal] Proposals for Modifying Validator Contract Functionality

Galaxy — Thu, 21 Mar 2024 07:14:40 +0000

1. KYC Mechanism Modification

Current Status: The current KYC mechanism is ineffective because anyone can upload KYC information without verification.

Proposal One: Add a voting mechanism to the uploadKYC function:

Only KYC-verified Masternodes can propose new candidates.
All Masternodes need to vote on the uploaded KYC information, and only those that receive more than 75% of the votes can pass KYC verification.

Proposal Two: Add a waiting period to the propose function:

After a candidate is proposed, the candidate address will not become a candidate immediately, but will enter a waiting list for two weeks.
Create a new voting method to vote on whether the candidate in the waiting period is invalid.
If 75% or more of the voters believe the candidate is invalid, the candidate will be removed from the waiting list and will not become a candidate.
If the candidate is not voted invalid during the waiting period, the candidate can become a candidate by calling the claimCandidate function to remove itself from the waiting list.

2. Modify Voting Parameters

Current Status: The request parameters for voteInvalidKYC and invalidPercent functions are invalidCandidate.

Suggestion: Change the request parameter to invalidOwner to make the system more stable.

3. Implement a Blacklist for Disqualified Owners

Current Status: If a owner is voted out, he will still have a chance to be proposed later.

Suggestion: This change introduces a blacklist mechanism to address the issue of repeatedly proposing unqualified owners. When an owner is voted out due to invalid KYC, both the owner and any candidates they propose will be added to a blacklist.

Blacklisted owners lose the ability to withdraw funds.
Blacklisted candidates cannot be re-proposed for ownership.

Soliciting Opinions:

Which of the two proposals for the first opinion is better?
Any other suggestions for the second opinion?
Any other suggestions for the third opinion?

[Informative] Subswap: Connecting Chains, Empowering Free Flow of Cross-Chain Assets

Galaxy — Wed, 20 Mar 2024 08:37:58 +0000

What is subswap

A token cross-chain Dapp based on XDC Zero will integrate token interoperability between multiple subnets and the mainnet, and also support token swaps on the mainnet.

OK ， Let’s review what is xdc zero is in case we forget

XDC Zero: A Cross-Chain Communication and Data Transfer System

XDC Zero is a cross-chain system that enables seamless communication and data transfer between different blockchains. It consists of three main components: endpoint contracts, a relayer, and checkpoint contracts.

Components:

Endpoint contracts: Endpoint contracts are deployed on both the source and destination chains. They serve as gateways for data transfer, receiving requests from applications on the source chain and forwarding them to the destination chain.
Relayer: The relayer is a critical component that facilitates data transfer between chains. It continuously monitors endpoint contracts for new data and transfers it to the corresponding endpoint contract on the destination chain.
Checkpoint contracts: Checkpoint contracts are responsible for verifying the authenticity and integrity of data transferred between chains. They achieve this by utilizing Merkle trees, which provide a secure and efficient way to verify data without requiring the entire blockchain to be downloaded.

Workflow:

The workflow of XDC Zero can be summarized as follows:

An application on the source chain initiates a data transfer request by sending a call data to the source chain's endpoint contract.
The source chain's endpoint contract stores the call data and notifies the relayer about the new data.
The relayer retrieves the call data from the source chain's endpoint contract and transfers it to the destination chain's endpoint contract.
The destination chain's endpoint contract requests the Merkle tree root from the destination chain's checkpoint contract to verify the authenticity of the call data.
The destination chain's checkpoint contract verifies the Merkle tree root and, if valid, executes the call data on the destination chain's application.

Benefits:

XDC Zero offers several key benefits, including:

Seamless cross-chain communication: XDC Zero enables applications on different chains to communicate and exchange data seamlessly without the need for complex integration or intermediaries.
Enhanced security and data integrity: XDC Zero utilizes Merkle trees to ensure the authenticity and integrity of data transferred between chains, providing a high level of security and trust.
Efficient data transfer: The relayer in XDC Zero optimizes data transfer by efficiently routing data between chains, minimizing latency and transaction costs.

Applications:

XDC Zero can be applied in a variety of use cases, including:

Cross-chain asset transfer: XDC Zero can be used to transfer assets between different chains, such as transferring tokens from a DEX on one chain to a lending protocol on another chain.
Cross-chain dApp development: XDC Zero can be leveraged to develop dApps that interact with multiple chains, enabling more complex and sophisticated functionality.
Cross-chain data sharing: XDC Zero can facilitate the secure sharing of data between different chains, such as sharing KYC information or market data across different blockchains.

OK ， We already know what xdc zero is. Let’s take a look at what subswap is and what the first xdc zero-based application consists of.

Subswap: A Cross-Chain Asset Transfer and Swapping Application

Subswap is a groundbreaking application built on XDC Zero that enables seamless cross-chain asset transfer and swapping on the mainnet.

Components:

Subswap contracts: Deployed on both the mainnet and subnet, these contracts facilitate cross-chain asset locking, minting, and swapping.
XDC Zero: Provides the underlying infrastructure for secure and efficient cross-chain communication and data transfer.

Workflow:

Cross-chain asset transfer:
- A user locks their tokens in the Subswap contract on the subnet.
- Subswap utilizes XDC Zero to transfer the locked tokens to the mainnet.
- The mainnet Subswap contract mints replica tokens with a 1:1 mapping to the original tokens.
Cross-chain asset swapping:
- Users can swap their mainnet tokens on the Subswap contract, e.g., tokenA for tokenB.
- This enables trading of tokens from different subnets on the mainnet.
- Users can then transfer their swapped tokens back to their desired subnet.

Benefits:

Seamless cross-chain asset transfer: Users can easily move their assets between subnets and the mainnet without the need for complex intermediaries.
Cross-chain asset swapping: Subswap enables users to trade tokens from different subnets on a single platform, increasing liquidity and market efficiency.
Enhanced security and data integrity: XDC Zero ensures the authenticity and integrity of all cross-chain transactions, providing a high level of security and trust.

Let's see what our demo can do now

First login the website
https://subswap-frontend-eta.vercel.app/bridge

1.Connet your wallet
(https://www.xdc.dev/uploads/articles/fxrcpqvxdswr877kf66a.png)

choose your network 3.submit your network name and network url 4.switch your network 5.choose your token 6.choose your token 7.choose the amount you want to send,and Select the address you want to receive tokens on the mainnet 8.you can see the transaction on the mainnet , you can receive the token

Subswap: Looking Ahead

Future Developments:

Enhanced Cross-Chain Functionality: Expanding cross-chain support to facilitate seamless asset movement from the mainnet back to individual subnets.
Mainnet Swapping: Introducing native swap functionality on the mainnet, allowing users to trade tokens directly without needing to interact with subnets.
Decentralized Relay Network: Building a more decentralized XDC Zero ecosystem, empowering individuals to run relayers and potentially earn rewards for their contribution.
Strategic Collaboration: Strengthening collaboration with the XDC team across engineering, marketing, and business development to accelerate Subswap's growth and adoption.

[Informative] Test the opcode after upgrade EVM in xdc devnet

Galaxy — Mon, 11 Mar 2024 12:47:58 +0000

Let's see which opcode we need to test it

About EIP-3855(PUSH0)

Let’s try to verify all of the above-mentioned details about PUSH0 opcode with an example and see if it actually does the magic. 🪄

We will take this small contract for example,

contract PushZero_Test{ uint256 public num; function set(uint256 _n) public{ num = _n; } }
Then, let’s Compile and Deploy this contract:

First, use older versions like 0.8.19 or 0.8.16, etc.
Then using the latest version, 0.8.20.
Contract Code Size

608060405234801561001057600080fd5b5060b18061001f6000396000f3fe6080604052348015600f57600080fd5b506004361060325760003560e01c80634e70b1dc14603757806360fe47b1146051575b600080fd5b603f60005481565b60405190815260200160405180910390f35b6061605c3660046063565b600055565b005b600060208284031215607457600080fd5b503591905056fea264697066735822122012c9c28a3afc19fc4abcdf6f9ad630831905962e9230729b065886c3b506f53564736f6c63430008130033
➡️ Contract bytecode size using older version = ~678 characters

6080604052348015600e575f80fd5b5060aa8061001b5f395ff3fe6080604052348015600e575f80fd5b50600436106030575f3560e01c80634e70b1dc14603457806360fe47b114604d575b5f80fd5b603b5f5481565b60405190815260200160405180910390f35b605c6058366004605e565b5f55565b005b5f60208284031215606d575f80fd5b503591905056fea26469706673582212205ee59545aaece46407d5982db44b8260dfa4e7227c4837321575367f34ef827864736f6c63430008140033
➡️ Contract bytecode size using 0.8.20 versions = ~646 characters

Deployment Gas Cost ⛽️
https://devnet.blocksscan.io/txs/0xc6a1f83325c8749115f45cf42f35e16a58452d57881eaad00fdf2e8d805651a2
➡️ Contract Deployment cost using older versions = ~61511 gas
https://devnet.blocksscan.io/txs/0xf87590988d34a24db47a045a70d567fb1168697b35d0739895496784c07f6fdd
➡️ Contract Deployment cost using 0.8.20 versions = ~58909 gas
As a result of this short experiment, we can clearly verify that with the inclusion of PUSH0 opcode, we now have:

Reduced contract code size, and
Reduced contract deployment gas cost
Hmmm, the opcode does its magic well. 🧐

Important Warning for Solidity Devs
If don't support PUSH0 opcode

And you might get an error that looks something like this 👇

About EIP-3198(BASEFEE)
I deployed the smart contract about this code

pragma solidity =0.8.20; contract TestPush0 { function getBaseFee() external view returns (uint256 number, uint256 basefee) { return (block.number, block.basefee); } function getRandom() external view returns (uint256 number, uint256 basefee) { return (block.number, block.prevrandao); } }

https://devnet.blocksscan.io/txs/0xe204c319c5f8805fb98aa6fabceb3eecd39171967b53272da8a0c213a908a272

The contract address is 0x25aAf52906f3b36DBA16FF22FBCb6d238Eb9a1d9

I can get the value from getBaseFee function, so it have supported the block.baseFee

Hmmm, the opcode does its magic well. 🧐
*About EIP-4399(RANDOM, PREVRANDAO) *
I can get the value from getRandom function, so it have supported the block.prevrandao

Hmmm, the opcode does its magic well. 🧐

[Informative] Upgrade Plan for XDCValidator Contract

Galaxy — Tue, 27 Feb 2024 05:26:20 +0000

Option 1: Deploy and Use a New Contract

Sub-option 1.1: Complete Abandonment of the Old Contract

At the first specified block number, disable all transactions in the old contract in Golang and inform all nodes to suspend transactions.
Import all data from the old contract into the new contract, ensuring functionality and data correctness.
At the second specified block number, switch MasternodeVotingSMC to the new contract in Golang.
Test the new contract thoroughly; if no issues arise, notify all nodes of a successful upgrade to use the new contract.

Sub-option 1.2: Permanent Coexistence of Old and New Contracts

Disable specific functions in the old contract in Golang, such as uploadKYC, propose, and vote.
Switch MasternodeVotingSMC to the new contract in Golang.
Notify all nodes to use the functions of the new contract.
The new contract reads asset data from the old contract but not other data, handling both the new and old contract's validatorsState data structures.
The old contract only allows withdrawals.

Sub-option 1.3: Temporary Coexistence of Old and New Contracts

Before a specified block number:

The new contract reads asset data from the old contract but not other data, handling both the new and old contract's validatorsState data structures.
In Golang, the old contract only allows withdrawals, disabling other functions.
Switch MasternodeVotingSMC to the new contract in Golang.
Notify all nodes to use the functions of the new contract.
Notify all nodes to withdraw from the old contract.

After the specified block number:

The new contract no longer reads asset data from the old contract.
Disable all transactions in the old contract in Golang.

Option 2: In-place Upgrade of Contract Code

Write tests for the new contract.
Backup the code of the old contract.
Extract the code of the new contract.
Modify Golang code to replace the contract's code at a specified block.
Notify everyone of changes in contract functionality.

For more details, refer to: XDCValidator Upgrade Discussion.

[Informative]XDC Zero :Advanced Cross-Chain System

Galaxy — Wed, 29 Nov 2023 06:04:43 +0000

What is XDC ZERO ?
Achieve unparalleled blockchain interoperability with XDC ZERO, ensuring frictionless data transmission and rigorous validation across a multitude of chains.

What's xdc zero for

verifiable generic message passing between networks
building block of inter-chain token transfer

Key Components

Light client-based verifier(CSC):verify TXs against the checkpointed headers
Endpoint:on-chain message reception and dispatch (to Dapp)
Relayer:cross-chain massage passer
Frontend:configuration management

Future : build anything cross-chain application base on xdc zero

For example: build bridge for token transfer from different chains

Demo for xdc zero

The current demo supports sending messages from subnet to devnet

if you want try , the step one switch to subnet ,then call devnet contract with address and input data

Tips : this is very new and under development ,please wait some more time for it to be perfected

Demo video

https://www.youtube.com/watch?v=NRtS3PwETVI&t=7s

Presentation

https://docs.google.com/presentation/d/1c2YPFY-abk8izXNGEzytg6SslLL1oOom8JOU0zHsfo4/edit?usp=sharing

Github

https://github.com/XinFinOrg/XDC-Zero

Website

https://xdc-zero.vercel.app/