CryptoDbSS / Ethereum - Bridge interoperability

a strong scability point is interoperability, How a software can work with another to increase its functionalities and users, CryptoDbSS has worked hard on this aspect, that is why Ethereum and its great ecosystem have been kept in view, one of the most notable is the implementation of its own EVM and smart contracts, these allow users to program decentralized applications within their blockchain, and a lot of unimaginable things, this article will demonstrate the implementation of these through the use of CryptoDbSS own software together with Ethereum, achieving interoperability between the two.

CryptoDbSS bridge Ethereum interoperability

This package is divided into 3 essential modules,
  • the user layer that interacts with the bridge's dapp
  • The Ethereum vendor Smart Contract
  • the bridge-core engine

Starting from the top, The User Layer.


For a user to be able to use the app, it is necessary to provide a graphical interface, This is served via HTTP, and uses Web3.js to be able to integrate with Metamask, the abi and the smart contract address ethereum is passing by the server for the interaction of user.


The user inputs the CryptoDbSS address and the amount of ETH they wish to transfer to CryptoDbSS, and subsequently presses the connect button.

The following demonstration was performed in Sepolia network (Ethereum testnet) with CryptoDbSS:





deployment of the smart contract on Sepolia at the address 0x4E6CAe59d77FB38D67ee4CeF7fE99c98422581B60x4E6CAe59d77FB38D67ee4CeF7fE99c98422581B6 :)
see on etherscan
CryptoDbSS Ethereum Smart Contract



Also included are some Python scripts to manage the smart contract and interact with its functions from the terminal.



python script performing bridge transaction to the ethereum smart contract using web3.py





This script calls the smart contract's infoAbout() function to display reference information about the contract



The Bridge Core

After the user interacts with the smart contract, the bridge takes responsibility. It reads the events emitted by the smart contract by filtering Ethereum blocks and indexing the relevant elements. These elements contain the CryptoDbSS address and the transferred value provided by the user. Next, the transactions are added to a queue for processing in CryptoDbSS, directed to the specified addresses. Finally, the bridge checks the transaction confirmation to complete its algorithm.

This module relies on parameter checks at each stage of its execution to ensure all events are indexed correctly and their transactions are subsequently processed. This is maintained even if the application fails or closes unexpectedly. To achieve this, the necessary data is logically stored in the module's database. When the application is reopened, this data is reloaded for continued processing.

This diagram explains how is based the alhgorithm


Source code Repo at github.com/CryptoDbSS/Eth-bridge


Thank you for reading this post. This work has required a great deal of consistency and dedication on my part, and I'm so glad you've made it this far.

suggestions, questions. steenjavier@gmail.com

Popular posts from this blog

Consensus: MatchMin

Image
Matchmin      A fundamental aspect in the blockchain area, if not the most important, is the consensus of the network of participants. It constitutes the basis of what is permissive and what is not in the network, which must be taken into account for the correct verification of the data, and how to act accordingly following a logic and algorithm through a common agreement between the participants. The Matchmin scheme is the following: the network is made up of 2 types of participants, Validators and Clients , each node is identified with a unique ID that the rest of the participants know, this is a cryptographic public key which it itself derived before joining the network and who only knows and uses its private key . further to recognizing each other within the network, the key is used to sign and corroborate the data that is sent between nodes and certify the authenticity of the sender . If someone tried to falsify data in advance, they would not be able...
Read more

Upcoming Update: Interoperability with Ethereum, External Chain Data Index with IPFS and Support for Federated Learning AI

Image
The next update for CryptoDbSS will introduce significant enhancements aimed to coming up interoperability between Ethereum and Introduce a new type of transaction for storage externad data reference bringing with it support for Federated Learning AI and data privacy. Key features of this update include: presentation of a new type of transaction new type of transaction relies on high extenal storage of data utilizing SHA (Secure Hash Algorithm) for reference it on the blockchain, using a protocol as IPFS , This will bring many practical uses, one focus of this will be the support Federated Learning AI. Interoperability with Ethereum This implementation will include a CryptoDbSS client configured through a Smart Contract on an Ethereum-based network with an end-point node. This setup will serve as a bridge between Ethereum and CryptoDbSS, enabling users to exchange funds across both network-chains seamlessly. Support for Federated Learning The update will al...
Read more

CryptoDBSS with IPFS/Web3 implementation

Image
CryptoDbss allows short messages to be published on the blockchain as a transaction. This can be annotated to be linked as metadata, for example, the SHA of a data or document. In this case, an example of its use with IPFS will be given. What is IPFS? Interplanetary File System, as its acronym IPFS , is a decentralized network protocol that allows its users to share any file, or data between connected nodes. It can also be called Web3 protocol, therefore anyone running a node can share or download what others share, without the need for a centralized server. These files, in turn, can be in directories, which allows for more orderly and precise indexing, to access them, it is necessary to know the CID (content identifier). This is generated when the file is uploaded. Each CID for each file and directory is unique, so there is only one unique one for each one, just like a hash, which is generally represented in base58. Many decentralized apps and DAO's that use the term w...
Read more