Quorum is public affairs software that helps you work smarter and move faster

Quorum

quorum

Former Michigan GOP Chair Kristina Karamo appeals a Kent County Judge&#x27;s decision calling a January vote to oust her, valid.

'They didn't have a quorum,' ex-GOP Chair Karamo says in dispute of court ruling

Tirunelveli Corporation councillors boycott meeting, delaying Budget session amid ongoing feud with Mayor Saravanan.

Lack of quorum: Tirunelveli Corporation’s council meeting, Budget session postponed - The Hindu

Ethereum is a general-purpose blockchain that is  more suited to describing business logic, through advanced scripts, also known  as smart contracts. Ethereum was designed with a broader vision, as a decentralized or world computer that attempts to marry the power of the blockchain, as a trust machine, with a Turing-complete contract engine. Although Ethereum borrows many ideas that were initially introduced by bitcoin,  there are many divergences between the two. The Ethereum virtual machine and smart contracts  are key elements of Ethereum, and constitute its main attraction. In Ethereum,  smart contracts represent a piece of code written in a high-level language (Solidity, LLL, Viper) and stored as bytecode in the blockchain, in order to run  reliably in a stack-based virtual machine (Ethereum Virtual Machine), in each  node, once invoked. The interactions with smart contract functions happen  through transactions on the blockchain network, with their payloads being  executed in the Ethereum virtual machine, and the shared blockchain state being  updated accordingly. If you are not  familiar with blockchain technology reading article is highly recommended. History  and Evolution of Blockchain Technology from Bitcoin If you like  to learn more Ethereum blockchain development (with Solidity programming), , Blockchain  Developer Guide- Introduction to Ethereum Blockchain Development with DApps and  Ethereum VM and Building Ethereum Financial Applications with Java and  Web3j API through Blockchain Oracles are highly recommended. Harness the Power of Distributed Storage IPFS and Swarm in Ethereum  Blockchain Applications The Ethereum main  network, and its corresponding test networks, are all open for public use. All  transactions made on the networks are 100% transparent, and anybody with access  to the network—which is potentially everybody—can see and access all data. The users of  these networks don't necessarily know each other: they are mutually distrustful  parties who must assume that the other participants in the network are  dishonest. For this reason, public blockchain networks require a way for such  parties to reach an agreement without needing to trust each other, and this is  where decentralized consensus algorithms, such as ( ),  come into the picture. proof of work PoW There are cases,  however, where transacting parties in a network are more trusting of each  other, and where the use of a blockchain isn't solely centered on allowing  mutually distrustful parties to interact. In this recipe,  we will explore the main types of blockchain networks available – public and  private—before looking in  more detail at how blockchains can be used in business settings, and what  options are currently available for keeping data private. We will then implement a very basic  private network that makes use of certain privacy features. Public versus private and  permissioned versus permissionless blockchains The Ethereum main  network is public, meaning anyone is free to join and utilize the network.  There are no permissions involved: not only can users send and receive  transactions, they can also take part in a consensus, as long as they have the  appropriate hardware to mine blocks. All parties in the network are mutually  distrustful, but are incentivized to remain honest by the mechanisms involved  in the PoW consensus. This is an example of a public, permissionless network. These networks offer high resistance to censorship and good data persistence,  but are less performant due to the decentralized nature of consensus. The idea of permission, when applied to blockchains, could take one of several  forms: it could be explicit, as in the case of an access control list, or  implicit, as in a requirement placed on users to enable them to join a network.  An example of a public, permissioned blockchain, could take the form of a  public proof of stake network, in which permission to participate in the  network as a validator is granted in exchange for a deposit or stake. Of more concern  for this recipe is the idea of networks run by companies, either for their own  internal use, or as a shared resource used by a group of companies wanting to  transact. Such networks are private: they are not open to the general public,  but only to those companies authorized to join. These are sometimes also  referred to as consortium blockchains, and as such, networks often also impose different types of permissions for different participants. For example, different members of the network may have read, write, or access permissions,  while another subset of members may take on the job of validation. Such private  networks can take advantage of permissioning to be more performant than their  public and permissionless counterparts. If a set of nodes can be trusted as  validators, then consensus can be reached more quickly. There is, however, a  tradeoff: a set of permissioned validators must be trusted to correctly and  honestly validate blocks. In the world of business, where time is money, such a tradeoff can often be worth  making. Privacy and anonymity in Ethereum We have so far  discussed the differences between public and private networks, where it is the  network itself, and access to it, which is either public or private. We now  turn our attention to the data—both transaction and contract data—inside a given  network. The Ethereum main  network can be joined by anyone. Furthermore, all transaction and smart  contract data is public, meaning all transactions between a and address can be seen by everybody using the network. There is  no way to hide these transactions, or the addresses transacting, and as such,  there's no way for a user on Ethereum to be truly anonymous. If a way were  found to link an address with a real-world identity—either at  the present time, or at a point in the future—then the identity  of the transacting party would be known.  This might seem obvious: on public networks, all data is public. What is less  obvious is that even in a private Ethereum network, data within the network is  visible to all participating nodes. to from Other cryptocurrencies, such as Zcash, Monero, and Dash,  provide differing degrees of anonymity, and we will briefly discuss two of the techniques for doing so in this recipe, and look at how these could be applied  to Ethereum. Monero uses a  type of digital signature called a ring signature, which helps anonymize the  transacting addresses as well as the amount being sent. It's possible to use a  similar technique in Ethereum by using mixing services based on ring  signatures, but these generally aren't accepted as being robust and scalable  methods that could be used in an enterprise. Zcash uses a  different technique, leveraging ( ) proofs. In this scheme, a user is able to prove  possession of some data without needing to reveal what the data is, and without  needing to interact with the user verifying the data. Some work has been done  to incorporate zk- SNARKs with Ethereum, though at the time of writing this work is still experimental. So, there is  currently no reliable method to make addresses and transactions anonymous in a  guaranteed way – what about the contents of those transactions? The contents of a  transaction, as well as the code and data associated with a smart contract, are  publicly viewable and cannot be obscured. Though a smart contract's code is  compiled to bytecode, it should not be assumed that an adversary wouldn't be  able to decompile and read the code. As such, sensitive information should  neither be hardcoded into a contract nor sent to it as part of a transaction. Zero-Knowledge  Succinct Non-Interactive Argument of Knowledge zk-SNARK What can be done,  however, is to encrypt any sensitive data off-chain before sending it to the  network. Using public-key cryptography, one method would be as follows: The sensitive data is  encrypted with the recipient's public key, which could have been published  either on- or off-chain The encrypted data is  sent either to a smart contract written for the purpose of receiving it, or in the data field of a normal transaction The  received data is decrypted using the recipient's private key Why are privacy and anonymity important? If we consider  the case of a private or consortium blockchain run by a group of companies,  then certain aspects of privacy are clearly important. For example, companies A, B, and C create a consortium  blockchain. Although the network is closed to the outside world, any  transactions between A and B are visible to company C, which could be  undesirable for a number of reasons, especially if the three companies are in competition with each other. In addition to any ( )  interactions between the companies themselves, it's possible the network would  involve some form of ( ) interaction, meaning  further types of confidentiality and privacy would be required. business-to-business B2B business-to-customer B2C Before we look in  detail at this recipe's project, let's take a look at the currently available Ethereum-based business platforms. The Ethereum  Enterprise Alliance The ( ) is a nonprofit working group  whose aim is to  define an open, standards-based architecture for business and enterprise use of Ethereum. Group members include many  large companies from  the world of software and finance,  such as Microsoft, Accenture, and J.P.Morgan. The group is currently working  toward defining the Ethereum Enterprise Architecture Stack, which itself will  help guide the development of the EEA's overall  standards-based specification. Enterprise Ethereum  Alliance EEA EEA's  specification will help define a standard way in which Ethereum's blockchain  can be used for business purposes. However, given the opensource nature of  Ethereum's codebase, adhering to EEA's specification won't necessarily be  required: Ethereum's codebase can be used in any way desired. Ethereum's  licensing According to Ethereum Foundation, different parts of the Ethereum technology stack are licensed  – or will be licensed—in  different ways. The core parts of  the stack, including the consensus engine, networking code, and supporting  libraries, haven't yet been licensed, but are expected to be covered by either  the MIT, MPL, or LGPL license. It's important to understand that the first of  these is a permissive license, while the latter two are more restrictive, and  restrict a user's ability to distribute any modifications under commercial  terms, therefore potentially restricting how businesses can use the code. Regardless of the  potential future restrictions that may appear once licensing is confirmed,  several enterprise-centric implementations of Ethereum have already been  created, with two such implementations being Quorum, created by J.P.Morgan, and  Monax. Later in the recipe we will be  discussing and implementing a project based on Quorum. Blockchain-as-a-Service ( ), is a service  that allows customers to create and run their own client nodes on popular public  blockchain networks, or to create their own private networks for their own use  and testing. The provisioned services are based in the cloud, and are analogous to the ( ) model.  Several of the large cloud computing providers are now offering BaaS, such as the following: - Microsoft Azure enables users to quickly deploy and manage applications in the cloud, and has templates available for Ethereum, Hyperledger, and R3's Corda. -  AWS Blockchain Templates is a very similar offering, and  again provides templates for Ethereum and Hyperledger. Further services are offered by IBM, HP, and Oracle, all along the same lines. Blockchain-as-a-Service BaaS Software-as-a-Service SaaS Quorum Quorum (https://www.jpmorgan.com/global/Quorum) is an enterprise-focused fork of the Ethereum codebase, and offers a private blockchain  infrastructure aimed specifically at financial use cases. It was created by  J.P.Morgan, and claims to address three of the topics that would make a public  blockchain network unsuitable for business use. Privacy, of both transaction and contract data , Higher performance and throughput Permission and governance. Privacy To achieve its  headline feature of making transactions and contract data private, Quorum  builds on Ethereum's existing transaction model, rather than completely  redefining it. Public  transactions and public contracts are visible to everyone on the network, and  make use of Ethereum's existing infrastructure—Quorum doesn't implement anything  different in this respect. As well as these public transactions, Quorum offers  the ability to mark transactions as private, making them visible only to the  intended recipients. This privacy is  achieved using public-key cryptography, specifically by setting the recipient's public  key in a new, Quorum-specific transaction parameter, privateFor. This allows the transaction to be encrypted, and therefore read-only by the owner of the private key. Higher  performance and throughput Private and  consortium blockchains are only open to certain authorized parties, rather than  completely open to the public. As a consequence, there is little need for the  consensus algorithms that are usually used between distrustful parties, namely  PoW in the case of the Ethereum main network. Quorum ultimately aims to offer pluggable and changeable  consensus algorithms, and currently there are two to choose from: : This provides a much faster block time—in the order of milliseconds as opposed  to seconds—as well as transaction finality, meaning once a transaction is placed into a block, there comes a point where it is impossible to remove it. A further difference from PoW is that this mechanism only creates blocks when  there are transactions ready to go into them. It doesn't create empty blocks in  the way that the Ethereum main network does. Raft-based  consensus : This is a PBFT-inspired algorithm that again includes short block times and  transaction finality. Istanbul Byzantine fault-tolerance Permission and  governance The third of  Quorum's headline features is its ability to permission only chosen nodes to  join a given network. This is achieved by each node in the network that has a  whitelist specifying the remote nodes that are permitted for both inbound and  outbound connections. We will later look in  detail at a practical implementation of this. The Quorum client At a high level, a Quorum client consists of the following  components: : This is based on the Ethereum  Geth client : This is a general-purpose  system for submitting information in a secure way, and is itself composed of and subcomponents. Quorum Node Constellation Transaction Manager Enclave Quorum Node is based on Ethereum's Geth client, but with a  series of changes: Ethereum's PoW consensus algorithm has been replaced.  There is currently a choice of two alternatives, which were briefly discussed previously. The P2P protocol has been modified to allow only  authorized nodes to connect, preventing connections from the wider public. The way Ethereum maintains and records its state has been changed to allow public and private states to be handled separately in two  different Patricia Merkle trees. Block validation has been altered to handle private  transactions as well as public transactions. The gas-pricing mechanism has been removed, though the  concept of gas is still used. Quorum Node So far, Geth has  been altered in such a way to allow both public and private transactions to occur. Constellation Constellation  could be considered a P2P system in which each node in the system can act as a  distributed key server and ( ), using PGP  encryption to encrypt messages. It is this part of Quorum that allows for  transactions to be made private, and is composed of two parts: the Transaction  Manager and Enclave. mail transfer  agent MTA The Transaction  Manager handles transaction privacy by storing and making transaction data  available, as well as exchanging transaction payloads with Transaction Manager  instances on other nodes. It does not have access to any of the private keys  required for encryption, which is the job of the Enclave. The Enclave's job is  to handle both key- generation and the encryption of transaction data. As its  name suggests, handling these jobs eparately allows  sensitive operations to be isolated. Summary In this article, we learn about private versus public  networks for Ethereum blockchain development. We also discussed the differences  between permissioned and permissionless blockchain networks as well as privacy  versus anonymity in Ethereum networks. At the end, we explored Quorum and  demonstrated its high level concepts and features. After this article, we move  on to tutorial. It shows you how to  implement a blockchain project based on Quorum step-by-step. If you like  to explore blockchain development with an alternative platform like Hyperledger  or learn about the projects of Hyperledger like Sawtooth or Iroha, visit page to  get the outline of our Hyperledger articles. Building  Enterprise Blockchain-as-a-Service Applications Using Ethereum and Quorum Comprehensive Hyperledger Training  Tutorials This article is written by Matt  Zand (founder of , ) in  collaboration with Brian Wu who is a senior Blockchain consultant at . About Authors High  School Technology Services Coding Bootcamps DC  Web Makers

Permission and Privacy For Blockchain Networks under Ethereum and Quorum

Recently, I stress-tested a Quorum network consisting of 2 nodes on separate machines, and the result was 140 tps… So, let’s see how to create a 2 node Quorum network in just a few minutes so that you can also stress-test your own Quorum network. But if you are new to Quorum, I suggest you , to get a better understanding of this article. go through the below article _This post marks the first in a new Quorum series I am starting in an effort to provide some easy to read instructions…_medium.com Quorum 101: Getting started with Quorum If you are all set, then let’s get started. Environment Used I am using 2 separate AWS machines ( ) for 2 separate Quorum nodes. Let us call them and . Ubuntu Server 16.04 LTS, t2-micro quorum-peer-1 quorum-peer-2 2 nodes on AWS Now, if you are running 2 nodes as above then let’s assume IP address of is and IP address of is . quorum-peer-1 IP-1 quorum-peer-2 IP-2 Also, open the following ports in the security group(it’s better to use same security group for both the nodes). ( ): Ports to open all TCP ports ,accessible from anywhere 9001 9004 21000 21003 22000 22003 50401 50404 Installing prerequisites Now, we have to install prerequisites on both the nodes(better option is to use a snapshot and use that for installing prerequisites on both the machines). To install the prerequisites just copy and run the below script on both the machines. Installing the Quorum application Now ssh into the and clone the below repository. quorum-peer-1 git clone ;cd quorum-testnode-1 https://github.com/vasa-develop/quorum-testnode-1 Similarly, ssh into and clone the below repository. quorum-peer-2 git clone ;cd quorum-testnode-2 https://github.com/vasa-develop/quorum-testnode-2 And Voila, you are set to test the network. P.S. special thanks to benchmarking scripts “chainhammer” by Dr Andreas Krueger, , London https://gitlab.com/electronDLT/chainhammer Electron.org.uk Initializing network Now execute the below command on both of the machines simultaneously as a (using ). super user sudo su ./start-peer.sh <IP-1> <IP-2>; tail -f qdata/logs/constellation*.log for example if is 12.45.78.55 and is 12.45.78.56, then the above command will be like IP-1 IP-2 ./start-peer.sh 12.45.78.55 12.45.78.56;tail -f qdata/logs/constellation*.log Make sure that the IP’s are in correct order, or the script will not work as expected You will see output similar to below ones. quorum-peer-1 output quorum-peer-2 output If you encounter some error then execute and again repeat the “Initializing network” step. ./stop.sh Press CTRL+C to exit the logs. Testing the Network Now, it’s time to test our network. In the execute the below command quorum-peer-1 ./runscript.sh script1.js Now, go to and execute the below command quorum-peer-2 python3 tps.py You will see output like the below one quorum-peer-2 output Now, here is the last command to measure the Execute the below command to start bombarding private transactions from to . Execute the following command in and you will see output similar to screens shown below. TPS. quorum-peer-1 quorum-peer-2 quorum-peer-1 python3 send.py quorum-peer-1 transaction bombarding quorum-peer-2 tps results Now as you can see, in the above screen that for first 1000 trxs the average tps rate is around 140 tps. Well, that’s better than many blockchains, but not really mind blowing. when you go for 1000 tps but end up with 140 tps… Well, that was it…your first Quorum network stress-test. using different machine sizes. Let’s see how high it can go. If you made it to the end then comment you TPS below Learned something? Click the 👏 to say “thanks!” and help others find this article. Hold down the clap button if you liked the content! It helps me gain exposure . Want to learn more? Check out my previous articles _IPFS Private Storage Network Series_medium.com Setting up your first distributed private storage network on IPFS: Part 1 _The whole world is going through the blockchain revolution. But wait…is this really what we dreamed of? Present…_medium.com 13 sidechain projects every blockchain developer should know about _This is a short guide, through which you can have your site running for free in few minutes!! So, let’s get started_medium.com Hosting a site for free on IPFS Clap 50 times and follow me on Twitter: @ vasa_develop

Quorum stress-test 1: 140 TPS

a bait to quorum lovers This post marks the first in a new Quorum series I am starting in an effort to provide some easy to read instructions covering topics I found online, particularly vast and hard to get started. In this post, we are going to cover a basic overview of Quorum. But if you want to get your hands dirty, then you can go . Also, I am working on stress-testing EOS and HyperLedger Fabric. I have already stress-tested Quorum and the results are out. here _Recently, I stress-tested a Quorum network consisting of 2 nodes on separate machines, and the result was 140 tps…_hackernoon.com Quorum stress-test 1: 140 TPS Stay tuned and follow me to get the updates in next few posts. But for now, let’s get started. What the heck is Quorum? In simple terms, Quorum is just a . So, why don’t we use ethereum instead? Well, here is where Quorum does its work. It provides a layer on top of ethereum which enables it to perform private transactions and makes it more robust by using different . Here are some of the key advantages of using Quorum over ethereum: blockchain platform based on ethereum consensus algorithms — Quorum supports private transactions and private contracts through public/private state separation and utilizing (see “Component Overview” below for explanation), a peer-to-peer encrypted message exchange for directed transfer of private data to network participants. Privacy Constellation — with no need for in a permissioned network, Quorum instead offers multiple consensus mechanisms that are more appropriate for consortium chains: Alternative Consensus Mechanisms POW/POS — a consensus model for faster blocktimes, transaction finality, and on-demand block creation. Raft-based Consensus — a PBFT-inspired consensus algorithm with transaction finality, by AMIS. Istanbul BFT — node/peer permissioning using smart contracts, ensuring only known parties can join the network. Peer Permissioning — Quorum offers significantly higher performance than public geth(ethereum). Higher Performance Now, if you just came out of nowhere into the blockchain, then you must be going crazy right now. what is this! So, let’s break things down a bit… Component Overview basic quorum architecture On the highest level Quorum consists of 3 main components namely: Quorum Node (modified Geth Client) Constellation — Transaction Manager Constellation — Enclave Lets explore them one-by-one. Quorum Node The Quorum Node is intentionally designed to be a lightweight fork of geth in order that it can continue to take advantage of the R&D that is taking place within the ever growing Ethereum community. To that end, Quorum will be updated in-line with future geth releases. The Quorum Node includes the following modifications to geth: ‘Proof of work’ consensus algorithm has been replaced with ‘QuorumChain’ consensus, a vote-based consensus mechanism. The P2P layer has been modified to only allow connections to/from permissioned nodes. The block generation logic has been modified to replace the ‘global state root’ check with a new ‘global public state root’. The block validation logic has been modified to replace the ‘global state root’ in the block header with the ‘global public state root’. The State Patricia trie has been split into two: a public state trie and a private state trie. This is done in order to keep the ledgers for the public and private transaction separate. Block validation logic has been modified to handle ‘Private Transactions’ Transaction creation has been modified to allow for Transaction data to be replaced by encrypted hashes in order to preserve private data where required. The pricing of Gas has been removed, although Gas itself remains. : The QuorumChain consensus algorithm is not yet supported by this release. Note Constellation is a general-purpose system for submitting information in a secure way. It is comparable to a network of MTA (Message Transfer Agents) where messages are encrypted with PGP. It is not blockchain-specific, and is potentially applicable in many other types of applications where you want individually-sealed message exchange within a network of counterparties. The Constellation module consists of two sub-modules: The Constellation Node (which is used for Quorum’s default implementation of a ) and Enclave. Constellation PrivateTransactionManager Constellation: Transaction Manager Quorum’s Transaction Manager is responsible for Transaction privacy. It stores and allows access to encrypted transaction data, exchanges encrypted payloads with other participant’s Transaction Managers but does not have access to any sensitive private keys. It utilizes the Enclave for cryptographic functionality (although the Enclave can optionally be hosted by the Transaction Manager itself.) The Transaction Manager is restful/stateless and can be load balanced easily. For further details on how the Transaction Manager interacts with the Enclave, please see the page. Transaction Processing & Privacy Constellation: Enclave Distributed Ledger protocols typically leverage cryptographic techniques for transaction authenticity, participant authentication, and historical data preservation (i.e. through a chain of cryptographically hashed data.) In order to achieve a separation of concerns, as well as to provide performance improvements through parallelization of certain crypto-operations, much of the cryptographic work including symmetric key generation and data encryption/decryption is delegated to the Enclave. The Enclave works hand in hand with the Transaction Manager to strengthen privacy by managing the encryption/decryption in an isolated way. It holds private keys and is essentially a “virtual HSM” isolated from other components. Again, for further details on the Enclave, please see the page. Transaction Processing & Privacy Below is a great article on how actually the private transactions occur in Quorum. _More and more companies have become interested in blockchain technology. The promise of this technology is big…_hackernoon.com Choosing private blockchain tech: Quorum And now, if you are still curious, then below is a list of useful links to get you more deep into the Quorum. do your research… : Quorum Consensus algorithm raft info-graphic explaination Raft documentation QuorumChain consensus Security & Network Permissioning: Security and network doc Using Quorum Developing contracts and setting up permissioned network Product Roadmap Roadmap Learned something? Click the 👏 to say “thanks!” and help others find this article. Hold down the clap button if you liked the content! It helps me gain exposure . Want to learn more? Checkout my previous articles. _Experts are suggesting quantum computing may render blockchain obsolete. As the tech giants such as Google and IBM are…_hackernoon.com Quantum Computing: Is it the end of blockchain? _This post marks the first in a new EOS series I am starting in an effort to provide some easy to read instructions…_hackernoon.com EOS 101: Getting started with EOS, Part 1 - Hacker Noon _IPFS Private Storage Network Series_medium.com Setting up your first distributed private storage network on IPFS: Part 1 _The whole world is going through the blockchain revolution. But wait…is this really what we dreamed of? Present…_medium.com 13 sidechain projects every blockchain developer should know about Clap 50 times and follow me on Twitter: @ vasa_develop

Quorum 101: Getting started with Quorum

More and more companies have become interested in blockchain technology. The promise of this technology is big: increased transparency, reduced dependence on intermediaries, reduced fraud and many others. There are a multitude of articles on the future of blockchain; however, they tend to be too abstract. In my view, there is not enough down-to-earth, specific use cases with concrete implementation examples. After all, when we choose a database technology, for example, all we really care about is how it can improve our business, not how it could disrupt the entire fabric of society. In the following series of articles, I will look at different blockchain products in the context of a single use case. The use case assumes implementation of a private blockchain by a group of organizations to store and share data. Private blockchains are not nearly as immutable and trustless as public ones (e.g. Bitcoin and Ethereum). However, this doesn’t mean there are no benefits to running a private blockchain, because sharing and replication of data is a common need in an enterprise setting. So here we’ll explore some of the most popular solutions enabling this and their benefits and drawbacks. But first, we’ll start with a look at our use case. Use case For the sake of ease and clarity, let’s consider an oversimplified version of a real life scenario from the finance industry. Once this simple use case is understood it is easy to extrapolate it to more complex scenarios. Here are the parties in this scenario: ( ) makes investment decisions (trades). Non-custodial means they don’t actually hold a client’s money. Instead, after a trade is executed they send directions to a custodian that moves the money appropriately. Non-custodial asset manager hedge fund . Usually a large and trusted finance institution that holds a client’s money and executes transfers on behalf of the hedge fund. Custodian needs to know about each trade to distribute payments to counterparties. Custodian . Invests into the hedge fund. Each client needs to view trades in their own account, but not other clients’ accounts. Client(s) It’s easy to see how there is a need to share transaction data among these 3 parties. We intentionally don’t consider moving actual money using the blockchain, since this is a well known use case. Instead, we’ll focus on a simple use case of transmitting data objects with the following fields: TradeID Trade Timestamp Trader Name Trade Size Trade Price Counterparty Name ClientID Other metadata can be added as well, including other fields specific to that trade type, e.g. option expiration date, etc. Requirements There are several requirements to this information flow: : Each trade, without exception, should be reported to the custodian. Non-delivery of instructions to the custodian can trigger serious adverse consequences (e.g. a default on a trade). Deliverability : It is important that only valid information is delivered to the custodian. Validity : The log of trades should be preserved at all times and never altered. Immutability : Only authorized parties should be able to view and send trade data. Security In the following series we’ll explore how different blockchain technologies allow for implementation of this scenario and whether or not there are any advantages over traditional approaches. However, to have something to compare against, let’s first look at some of the conventional approaches to solve this. Conventional approach Currently, such a scenario could be implemented in many different ways. Here is a non-exhaustive list of solutions from simplest to more sophisticated: The hedge fund could manually send trade info in an email. An employee of the custodian then reads these emails and inputs the data into the custodian’s database. The hedge fund uploads a file with trades to the custodian’s secure FTP where it gets picked up by a script which then imports them into the database. The hedge fund executes the custodian’s secure API call to submit trade data. Blockchain approach Since blockchain is essentially a distributed ledger with the inherent ability to sync data among nodes, at first glance it makes sense to use it for this use case. In short, it looks like this: each party runs a local blockchain node (an application running in the background) that is synced with other nodes and is able to send and/or receive trade data in near real-time. Such a setup is called a “private blockchain”, since this network is run by a limited number of entities that have exclusive access to it. In the first part of the series we’ll look at Quorum, a blockchain solution developed by JP Morgan. In the future articles we’ll look at Hyperledger Fabric, BigchainDB, Tendermint and others. Quorum Quorum is a fork of Ethereum code base that adds a different consensus protocol, encrypted storage and permissioned access to a standard set of Ethereum features, such as distributed ledger and Smart Contracts. In addition, it provides Constellation protocol to exchange encrypted messages. Why not just use private Ethereum chain? For this purpose, Ethereum has 2 major drawbacks: a) anyone can connect to the network; b) all data inside smart contracts is visible to all nodes. Quorum solves these, albeit at a cost of moving some data transfer and storage off-chain. You can find implementation details in Quorum’s . In short, the private transactions work as follows: each node has both a public and a private key. When party A sends a private transaction to party B it goes through these steps (I omit some implementation details for the sake of simplicity): wiki Generate a new symmetric key and encrypt the transaction using this key. Generate SHA3–512 hash from the encrypted transaction. Encrypt the symmetric key from (1) using party B’s public key. Transmit the hash from (2) on-chain, then transmit the transaction and the symmetric key (both encrypted) to party B off-chain. Party B decrypts the symmetric key using party B’s private key then generates a hash of the encrypted transaction, confirms that it matches the on-chain hash — to make sure that transaction data is correct. Party B fully decrypts the transaction using the symmetric key from (5). Private transactions in Quorum The reason why we can’t store the full transaction on-chain is because, by definition, each node has an exact copy of the blockchain. Therefore, if we store it on-chain it will be visible to everyone. The workaround is storing only the hash on-chain and the rest off-chain. Hash doesn’t allow us to reconstruct the transaction data; however, it allows us to validate that transaction data is correct (if data is changed — its hash will be different and will not match the on-chain hash). This is how we get immutability and privacy at the same time. Implementation Full example code can be seen in the . The solution is quite simple and has the following components: Smart Contract, Private Transactions and New Trade Notifications. Let’s look at each of them. github repo Smart Contract Smart Contracts is a feature of Ethereum that allows you to publish a program on blockchain. You can then execute its code by issuing a transaction. A smart contract can store data “inside of itself” and have a logic determining who can modify and view its data along with other functions. When nodes receive a transaction referencing a smart contract’s method they execute it and record data changes, if any, in the blockchain. Below is the shortened version of the TradeData smart contract code. The contract has the following features: Ability to add a new trade using the method. Only the owner of the contract, in our case the Hedge Fund, is allowed to add new trades. addTrade Ability to retrieve Trade object by ID. Ability to receive a notification when a new trade is added. contract TradeData is mortal { struct Trade {string internalTradeID;uint utcTimestamp;string traderName;int sizeBig;uint priceBig;string counterparty;string client;} event NewTradeEvent(uint tradeID); function addTrade(string internalTradeID, uint utcTimestamp, string traderName, int sizeBig, uint priceBig, string counterparty, string client) public returns(uint) {...} function getTradeByID(uint tradeID) public constant returns  (string, uint, string, int, uint, string, string) {...} function getLastTradeID() public constant returns (uint retVal) {...} } (you can view complete contract code ) here Private Transactions As discussed earlier, unlike the pure Ethereum implementation, Quorum allows users to send private transactions. This includes transactions that modify a contract’s state. This is done by adding parameter to the transaction payload. A state that is added via a private transaction is only visible to parties specified in . This makes it easy to share trades with just one client and not all clients. privateFor: [“RECEPIENT_PUBLIC_KEY”] privateFor New trade event Nodes can subscribe to be notified as soon as new trades appear in the blockchain. A node only receives a notification if it is allowed to view the corresponding trade. That’s how the custodian can monitor when a new trade comes in and can process it. Conclusion Although Quorum doesn’t appear to be fully production-ready at the time of writing, its architecture is quite simple and makes sense. Being based on Ethereum, it inherits all its nice features such as smart contracts, Solidity contract language, wide developer adoption, and easy-to-use JavaScript API. Given that it is a free open-source technology, it is easy to see how in the future it could become a compelling alternative to traditional proprietary data sharing solutions. Such solutions can often be expensive, error prone, hard to maintain and scale. An open-source standard implementation would facilitate data sharing among companies without the need for multiple custom integrations. Now that we’ve displayed a real-life application of private blockchain technology, we’ll take the same use case and look at HyperLedger Fabric implementation in the next article. Comments, questions or suggestions? Feedback is welcome and appreciated.

Choosing private blockchain tech: Quorum

Executing Public & Private Transactions on JPMorgan’s Quorum with Web3

How to set up a private blockchain with Quorum

Welcome to the third and final part of my series on replication in distributed systems. If you have missed the first two parts of the series, I would advise you to read them first, as this comes off as a storyline. Data Replication in Distributed Systems - Part 1: Understanding the Need for Database Distribution Data Replication in Distributed Systems – Part 2: Conflict Resolution and Multi-Leader Configuration In this blog, we will discuss… well, let’s dive right in without formalities! Leaderless Replication In a leaderless implementation, the client directly sends the writes to several replicas and waits for the majority of them to acknowledge, compared to a setup with one or more leaders where a leader exists to coordinate the writes. What happens when a node goes down? In a leader-based configuration with one leader and two replicas, we need to perform if we want to continue to process writes. But in a leaderless configuration, failover doesn’t exist. So when the unavailable node comes back online, it has missing writes, meaning it has data. failover stale This problem can easily be solved by sending the read request from the client to not just one replica but to several nodes in parallel. The client may receive different versions of the data that may be up-to-date or stale. Version numbers are used to determine which value is newer. When the unavailable node comes back online, it has stale data. There are two mechanisms to catch up on the writes: - When a client makes a read request from several nodes in parallel, it can detect the node/s having stale data. The client sees the node which has stale data and writes back the newer value. This approach works well for values frequently read. Read Repair - A background process runs constantly to look for differences in the data between the replicas. This approach doesn’t copy writes in the same order they are written to the up-to-date replica Anti-Entropy Quorums Consistency Quorums aren’t necessarily the majority – the only thing that matters is that the sets of the nodes used by the read and write operations overlap in at least one node. If there are replicas, every write must be confirmed by nodes to be considered successful, and we must query at least nodes for each read. As long as , we expect to get up-to-date values. Reads and writes that obey these r and w values are called . n w r w + r > n quorum reads and writes The quorum condition w + r > n allows the system to tolerate unavailable nodes: if w < n, we can still process writes if a node is unavailable if r < n, we can still process reads if a node is unavailable But even with quorum consistency, there are edge cases where stale values returned: If a is used, the w writes can end up on different nodes than the r reads, so there is no longer a guaranteed overlap between the r and w nodes. sloppy quorum If two writes occur concurrently, it’s not clear which one happened first. The only safe solution is to merge the concurrent writes. If a winner is picked based on the timestamp (LWW - last write wins), writes can be lost due to clock skew. If a write happens concurrently with a read, the write may be reflected on only some of the replicas. It’s undetermined whether the reads return the old or new value. If the write succeeds on fewer than w nodes and fails on the remaining ones, it is not rolled back on the replicas where it succeeded. It means that if a write is reported as failed, subsequent reads may or may not return the value from that write. Sloppy Quorums & Hinted Handoff In large clusters with significantly large n nodes, the client can likely connect to some database nodes during the network interruption, just not the nodes that needed to assemble a quorum for a particular write or read. Is it better to return errors to all requests when we can’t reach a quorum, or should we accept the writes anyway and write them to some nodes that are reachable, but aren’t among the n nodes on which the value lives? This is called . Writes and reads still require w and r successful responses, but those may include nodes that aren’t among the designated n “home” nodes for a value. Once the network interruption is fixed, any writes that one node temporarily accepted on behalf of another node are sent to the appropriate “home” nodes. It is called . sloppy quorums hinted handoff Sloppy quorums are particularly useful for increasing write availability. As long as any w nodes are available, the database can accept the writes. However, this means that even when w + r > n, you cannot be sure to read the latest value for a key because the latest value may have been temporarily written to some nodes outside of n. Last Write Wins (LWW) Leaderless replication is designed to tolerate conflicting concurrent writes. One approach to achieving eventual convergence is to declare that each replica needs only to store the most “recent” value and allow “older” values to be overwritten. We can attach a timestamp to each write, pick the biggest timestamp as the most “recent” value, and discard any writes with an earlier timestamp. This conflict resolution algorithm is called . last write wins LWW achieves the goal of eventual convergence but at the cost of durability. If there are several concurrent writes to the same key, even if they were all reported to be successful by the quorum to the client, only one of the writes will be able to survive, and the others will be silently discarded. It may cause LWW to drop writes that aren’t concurrent. Caching is one use case where lost writes are acceptable, and LWW is a good choice. But if losing data isn’t acceptable, then LWW is a poor choice for conflict resolution. Defining Concurrency & “Happens-Before” Relationship An operation A happens before another operation B if B knows about A, B depends on A, or B builds upon A. The key to defining concurrency is to know whether one operation happens before another operation. In concurrency, the timestamp doesn’t matter. We call two operations concurrent if they are unaware of each other, regardless of the physical time at which they occurred. Capturing the Happens-Before Relationship The server can determine whether two operations are concurrent by looking at the version numbers. The server maintains the version number for every key and increments the version number every time that key is written. The server stores the new version along with the value written. When a client reads a key, the server returns all the values that haven’t been overwritten with the latest version number. A client must read the key before writing. When a client writes a key, it must include the version number from the prior read and must merge all the values it received in the prior read. When the server receives a write with a particular version number, it can overwrite all values with that version number or below, but it must keep all values with a higher version number. Version Vectors Using a single version number to capture dependencies between operations isn’t sufficient when multiple replicas are accepting writes concurrently. Instead, we need to use a version number per replica per key. Each replica increments its version number when processing a write and keeps track of the version numbers it has seen from each of the other replicas. This information indicates which values to overwrite and which values to keep as siblings (concurrent values are called siblings). The collection of version numbers from all replicas is called . version vector Version vectors are sent from the database replicas to clients when values are read and need to be sent back to the database when a value is subsequently written. It helps the database to distinguish between overwrites and concurrent writes. Parting Words The third part and final part of the blog series introduced quorum consistency for leaderless replication, the LWW concurrency model, and version vectors. This rounds up my blog series on replication in distributed systems. If you liked the blog, don’t forget to share it. Also, follow me on , , , and other social platforms, and tag me. You may also write to me at to share your thoughts about the blog. Twitter LinkedIn Peerlist guptaamanthan01@gmail.com References Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann Originally posted on https://manthanguptaa.in/posts/replication_in_distributed_systems_part_3/

Data Replication in Distributed Systems - Part 3: Quorum Consistency and Last Write Wins

Success J.P. Morgan Chase connected 220 banks to it’s Quorum-based and completed planned using Microsoft Azure and National Bank of Canada with the intent to streamline a number of financial processes. Interbank Information Network integration work This includes but is not limited to; settlement, origination, and interest rate payments. The results were exciting for JPM Coin awaiters. Real-time settlements have been integrated, indicating they’ve successfully launched a digital currency. . Source Why is this bizarre to many? Jamie Dimon’s Love of Bitcoin According to J.P. Morgan’s official website they’ve supported cryptos; “We have always believed in the potential of blockchain technology and we are supportive of cryptocurrencies... Some in the crypto-community have highly disagreed with this statement. Jamie Dimon is the Chairman and CEO of J.P. Morgan Chase, the largest bank in America, also served on the board of directors of the Federal Reserve Bank in New York. , so it was no shock when his negative comments on Bitcoin made . It’s wise to assume Dimon knows a little about money world news During the ‘Delivering Alpha’ conference in 2018, Jamie Dimon laughed, “ .” This was following Dimon’s long history of Bitcoin bashing statements. My daughter bought some bitcoin and it went up and she thinks she’s a genius now Looking back we heard him state Bitcoin was a “ .” as early as 2014. terrible store of value A year later, in 2015 he said “ ”. Bitcoin will not survive September 2017 he very publicly termed Bitcoin a “ ” and threatened to fire any of his staff that used it. Dimon later said he regretted stating BTC was a “ ”. fraud fraud Source Not a Fan of Bitcoin, Loves Blockchain Dimon never had anything but praise for the underlying technology found in Bitcoin, evidenced not only by his statements, but also within his actions. J.P. Morgan Chase has been experimenting with blockchain technology for several years. With the desires of regulation, J.P. Morgan plans to evolve within the digital revolution and continues to be one of the largest ‘cash cows’ in the world with $2.5 trillion worth of assets Source Their site proudly proclaims; "J.P. Morgan this month became the first U.S. bank to create and successfully test a digital coin representing a fiat currency. The JPM Coin is based on blockchain-based technology enabling the instantaneous transfer of payments between institutional clients. We sat down with Umar Farooq, head of Digital Treasury Services and Blockchain, to find out more about the announcement and what it means for the future of payments" Despite Jamie Damon’s disdain for Bitcoin, JPM Coin mimics Bitcoins behaviors by speeding up transactions between users. Although, it differs related to JPM Coin’s design; as it is a fiat-collateralized Stablecoin pegged to the US Dollar. This, correctly stated makes to introduce its own digital coin for real-world usage. J.P. Morgan Chase the first major US bank The love of Blockchain blossoms… CoinDesk Exclusive on Zether & Quorum On May 28th 2019, J.P. Morgan Chase announced it’s “blockchain team has developed a privacy feature for ethereum-based blockchains, obscuring not only how much money is being sent but who is sending it.” “Revealed exclusively to , JPMorgan to the a fully decentralized, cryptographic protocol for confidential payments, compatible with ethereum and other smart contract platforms and designed to add a further layer of anonymity to transactions. The New York-based financial institution will open-source the extension Tuesday, and is likely to use it with the bank’s homegrown, private version of ethereum.” . CoinDesk has built an extension Zether protocol, Quorum, Source JPM’s head of Quorum and crypto-assets strategy, Oli Harris explained what the extension does to CoinDesk: “In the basic Zether, the account balances and the transfer accounts are concealed but the participants’ identities are not. So we have solved that. In our implementation, we provide a proof protocol for the anonymous extension in which the sender may hide herself and the transactions recipients in a larger group of parties." exclusive interview with Harris pointed out; “Zether’s confidential payments architecture incorporates an employed by ethereum, as opposed to the unspent transaction output, or UTXO-based approach, which the bitcoin client uses. The UTXO is also a feature of the privacy-oriented cryptocurrency zcash, which the original ZKP component of Quorum was based on. In this way, the extension could benefit not only users of Quorum, but also enterprises building on top of other ethereum variants — or, conceivably, businesses leveraging the public ethereum chain.” CoinDesk’s account-based approach Photo & Quote Source from CoinDesk When we think about the community building on top of Quorum,” said Harris, “if anyone is looking to get an efficient trustless mechanism for trustless and anonymous payments in a consortium then that’s when it’s relevant. That’s why we wanted to open-source it back to the community so anyone can build on it further and continue enhancing it and potentially put it into their use cases as needed. Harris said the extra dose of cryptography to obfuscate participant identities didn’t appear to have that effect with Zether, concluding: The performance is quite good; we had done multiple iterations to improve it and we are doing the verification in solidity smart contracts. We’ll be including in our report the performance measurements for proving and verification. The Race for First. Second. & Third. J.P. Morgan is actually not the first bank to launch a Stablecoin, and it won't be the last. Although, JPM Coin is making major headlines in relation to being backed by the top bank in America, it was not the first Stablecoin launched by a US bank. The first was actually , launched by Signature Bank on December 4, 2018, two months before J.P. Morgan Chase’s media release of their plans for a digital currency. Signet With all the Libra Stablecoin talk from Facebook and the wallet app launching next year, Mark Zuckerberg announced partnership among the various companies signed up to invest around $10 million each in Libra. These include but are not limited to; Visa, Inc. ( ) and Mastercard, Inc. ( ), PayPal Holdings, Inc. ( ), Uber Technologies, Inc. ( ). Calibra V MA PYPL UBER For bes in 2018 states; “ Some 1.7 billion adults worldwide still don’t have access to a bank account, according to data released by the World Bank. The situation is slowly improving, however, with 1.2 billion people getting access to proper banking since 2011, including over half a billion people in the last three years alone.” With these facts presented, federally recognized institutions, globally are deciding if a Stablecoin is going to be beneficial to their bank or not. Many are experimenting, as to not get left behind as the financial technology continues to grow. Need to know more about Stablecoins? I’ve written a lot on them… Complete & Simple Guide to Understanding StableCoins here . Asset-Collateralized coins, also known as, Fiat-Collateralized StableCoins found in my publication here . I also covered Crypto-Collateralized StableCoins. That article can be viewed here . Then switched things up a bit and visited the only Non-Collateralized StableCoin Category, Seigniorage Supply (Algorithmic) StableCoin Model . Enjoy the description of the futuristic currency model here . Next? A simple to understand category among a Asset-Collateralized group; Metal-Collateralized Stablecoins found here , with a long list of promising projects. Lastly, combining asset backed and non collateralized crypto’s, we have our Hybrid StableCoin Model Category. View this here . If you’d like to learn how to “get ahead” with your newfound StableCoin knowledge, visit my very last part of my Ebook here. “ A Guide to Using Stablecoins to Increase & Protect Your Assets.” Tell me what you think. What am I missing? What would you add? What’s your personal opinion on StableCoins? I’d love to professionally discuss, collaborate and connect with you all. Would love any feedback, positive and negative; as I’m only here to improve and educate myself/others. So, how can we mutually benefit one another? 💻 Let’s Connect on Social Media 📱 -@ LinkedIn -@ instagram -@ Twitter -@ Facebook

J.P. Morgan Chase’s Stablecoin has it’s Beta Users Learning Crypto

Everything wrong with Ethereum in 2019

Building on top of Ethereum has never been easier.Frameworks such as the ever popular and make it very easy for developers to quickly deploy contracts and interact with them. Truffle-suite Embark These frameworks unfortunately is best suited for testing and experimentation. What happen’s if we want to have a server connect to a blockchain, and then have it interact with Smart Contracts? Enter Web3. Web3 is a wrapper for Ethereum’s JSON-RPC API. Despite being an abstraction library, it still offers great flexibility and a large deal of complexity. In this tutorial, we’ll be developing on top of the network. Quorum is , so you’ll find that this guide will work perfectly well with Ethereum as well. I choose Quorum specifically because transactions are near instant, and i don’t need to refill my wallet with test ethers. All transactions are free, so we do not need to get test Ethers. Quorum extremely similar to Ethereum We’ll split this guide into two sections: and Contract Deployment Contract Interaction. Creating your Quorum Network At Chainstack, you can create your own Quorum Node easily. We have a free trial for 14 days, so hop on over to our to get started. console If you don’t want to use Quorum, you can connect to your own Ethereum node via Geth or Parity, but you can deploy your own node on Chainstack as well for free :) Disclaimer (I work for Chainstack) Contract Deployment Let’s prepare a simple Smart Contract called Hello.sol pragma solidity ;
contract Hello { text; ;
    constructor( memory _text) {
        text = _text;
    } { text;
    } {
        text = _newText;
    } { ;
    }
} 0.5 .0 string ( ) event received address _received string public function ( ) view ( ) getText public returns memory string return function ( ) changeText memory _newText string public function ( ) payable pay public emit ( ) received msg.sender The contract accepts String argument to deploy it. You can also call to get back the string that you set during deployment. To change the text, call and supply it with your new string :) Hello getText() changeText() Finally, the contract has a payable function called A payable function is a function that can be sent Ethers to, and then the function is executed. We’ll see how all of this is done using . pay(). Web3js We’ll also assume that you know how to compile and get the bytecode and ABI of the contract. An easy way to do so if to use REMIX, and copy the bytecode and ABI that it provides. Let’s start by creating a contract instance: Contract = web3.eth.Contract(abi) const You have to supply the ABI so Web3 knows the specifications of each function in the Contract. Next, deploy the contract. .deploy({ : contractData.bytecode, :[title],
}) data arguments The deploy function accepts an object. This object contains two things, the bytecode of the contract (which you obtained via REMIX) and the arguments for the constructor. While this function is called , it actually doesn’t deploy the contract to the blockchain. We’ll have to use to finalize this process: .deploy() .send() .send({ : address, : , gasPrice: , }) from gas 470000000 //9000000 for Ethereum 0 // 3000 for Ethereum (3000 wei) also takes in three key objects: .send() 1. From Address 2. Gas Limit (or just Gas) 3. Gas Price Let’s chain .deploy() and .send() of this together: contract.deploy({ : contractData.bytecode, :[title],
    })
    .send({ : address, : , : ,
    }) data arguments from gas 470000000 gasPrice 0 This will return a promise, which contains the transaction receipt for the deployment of the contract. Hello In summary, to deploy a contract you need to: 1. Get the bytecode and ABI of the contract 2. Create a contract instance 3. Include the bytecode and constructor arguments in . deploy() 4. Send it to the blockchain using .send() Once deployed, the transaction receipt contains the address of the Smart Contract. We’ll need this in the next section. Contract Interaction Contract Interaction is slightly more complicated. The contract has three functions, , and getText() changeText() pay() Let’s get an instance of the smart contract so your javascript file can interact with it. contract = Web3.eth.Contract(ABI,contractAddress) const We’ll have to supply the ABI so web3 knows how to interact with the contract. This time, we supply the contractAddress, so Web3 knows where to send our calls to. With the contract instance, we can now access the function: getText() text = Contract.methods.getText().call({}) const await The important thing here is the object. The contract Object exists as a nested Object in javascript, and the function calls are stored in the object. .methods methods Since ) is a view function, it does not make any changes to the blockchain. Thus, we chain the the function with . also returns the value in the returns() argument of the function in the Smart Contract, and the transaction receipt. getText( .call({}) call() not How about the function? Take a look: changeText() Contract.methods.changeText( ).send({ : accounts, : , : }) 'New Text' from gas 470000 gasPrice 0 For non-view functions, or rather functions which changes the state of the blockchain, we have to chain it with . Recall how we used during contract deployment. This makes sense because deploying the contract is also changing the state of the blockchain. You’ll get the transaction receipt as the response. .send() .send() The final function is a function that accepts ether. Let’s see how we can do this using Web3. pay() Contract.methods.pay().send({ : accounts, : , : gasPrice: }) from gas 470000 value 1000000000000000000 // in WEI, which is equivalent to 1 ether 0 We still chain it with the function, but this time we include the value parameter in the object to be sent. This value has to be in wei, and not Ether. So do your conversions accordingly. send() But wait, what about payable functions that returns a value? How do we return value but also send it some Ether? The answer is to use first, and then . .send() .call() That’s it! You’re now an expert in Web3 :P Don’t hesitate to drop me a message. Explore Chainstack Website: Console: www.chainstack.com console.chainstack.com

Essential Web3 calls

PIECHAIN Demo: Exploring a Practical Blockchain Interoperability Framework

পাইচেন ডেমো: একটি ব্যবহারিক ব্লকচেইন ইন্টারঅপারেবিলিটি ফ্রেমওয়ার্ক অন্বেষণ করা

PIECHAIN-Demo: Erkundung eines praktischen Blockchain-Interoperabilitätsrahmens

Demostración de PIECHAIN: Explorando un marco práctico de interoperabilidad de Blockchain

Démo PIECHAIN : Explorer un cadre pratique d'interopérabilité de la blockchain

PIECHAIN डेमो: एक व्यावहारिक ब्लॉकचेन इंटरऑपरेबिलिटी फ्रेमवर्क की खोज

PIECHAIN デモ: 実用的なブロックチェーン相互運用性フレームワークの探究

PIECHAIN 데모: 실용적인 블록체인 상호 운용성 프레임워크 탐색

Demonstração PIECHAIN: Explorando uma estrutura prática de interoperabilidade Blockchain

Демонстрация PIECHAIN: изучение практической структуры взаимодействия блокчейнов

PIECHAIN Demosu: Pratik Bir Blockchain Birlikte Çalışabilirlik Çerçevesini Keşfetmek

Bản trình diễn PIECHAIN: Khám phá Khung tương tác Blockchain thực tế

PIECHAIN 演示：探索实用的区块链互操作性框架

LLC is one of the most popular business structures in the USA for small businesses, providing lots of opportunities and specific administrative operations. LLC operating agreement is used to ensure legal compliance for this type of business structure, including ownership and member duties division. This agreement can help protect companies and mitigate risks in terms of corporate shareholders' liabilities. 📍LLC Operating Agreement is a document that specifies the terms of LLC regarding the members and their roles. It is worth mentioning that in some states incorporating LLC requires signing this type of agreement as a set of crucial rules and internal operating procedures. As it serves as a roadmap for minimizing conflicts and mitigating risks, it's crucial to include such elements in the document: Member ownership & rights This section details each member's ownership percentage, voting rights, and responsibilities within the LLC. Profit & loss sharing The agreement clearly defines how profits and losses are distributed among members, ensuring fairness and transparency. Management structure This section outlines the framework for managing the LLC, including the roles and responsibilities of managers or designated members. Meetings & voting Procedures for holding meetings, voting on crucial decisions, and defining quorum requirements are established to facilitate efficient decision-making. Member buyouts & succession The agreement details the process for a member exiting the LLC, either through buyouts or in the event of death. This ensures a smooth transition and safeguards business continuity Why use an LLC Operating Agreement to Ensure Legal Compliance? Let's Discover Its Assets: A well-crafted agreement strengthens the separation between your personal assets and the LLC's liabilities. If the LLC incurs debt, creditors cannot go after your personal belongings (like your car or house). The agreement outlines ownership percentages, member roles, profit-sharing mechanisms, and voting rights. This transparency minimizes confusion and sets clear expectations for everyone involved. You can tailor procedures for meetings, voting, and management to your specific needs. This flexibility surpasses the limitations of generic state-mandated rules. A well-defined agreement establishes a process for resolving disagreements among members, preventing conflicts from disrupting your business trajectory. For single-member LLCs, the agreement can outline how ownership will transfer in case of death or disability Nevertheless, it`s needed to oversee some liabilities and considerations of such document Without legal assistance, an agreement will not contain your unique circumstances and ensure effective potential issues management. It requires considering provisions for capital contributions, distribution of assets upon dissolution, and non-compete clauses (if applicable). The agreement needs routine monitoring and check-ups as needed to provide consent of all members to adapt to business needs. In conclusion, the LLC Operating Agreement is crucial for the making of financial, management, and operational decision processes. The agreement defines the business roadmap and clarifies various procedures. LLC is one of the most popular business structures in the USA for small businesses, providing lots of opportunities and specific administrative operations. LLC is one of the most popular business structures in the USA for small businesses, providing lots of opportunities and specific administrative operations. LLC is one of the most popular business structures in the USA for small businesses, providing lots of opportunities and specific administrative operations. LLC operating agreement is used to ensure legal compliance for this type of business structure, including ownership and member duties division. This agreement can help protect companies and mitigate risks in terms of corporate shareholders' liabilities. LLC operating agreement 📍 LLC Operating Agreement is a document that specifies the terms of LLC regarding the members and their roles. It is worth mentioning that in some states incorporating LLC requires signing this type of agreement as a set of crucial rules and internal operating procedures. LLC Operating Agreement is a document that specifies the terms of LLC regarding the members and their roles. It is worth mentioning that in some states incorporating LLC requires signing this type of agreement as a set of crucial rules and internal operating procedures. As it serves as a roadmap for minimizing conflicts and mitigating risks, it's crucial to include such elements in the document: Member ownership & rights Member ownership & rights Member ownership & rights This section details each member's ownership percentage, voting rights, and responsibilities within the LLC. Profit & loss sharing Profit & loss sharing Profit & loss sharing The agreement clearly defines how profits and losses are distributed among members, ensuring fairness and transparency. Management structure Management structure Management structure This section outlines the framework for managing the LLC, including the roles and responsibilities of managers or designated members. Meetings & voting Meetings & voting Meetings & voting Procedures for holding meetings, voting on crucial decisions, and defining quorum requirements are established to facilitate efficient decision-making. Member buyouts & succession Member buyouts & succession Member buyouts & succession The agreement details the process for a member exiting the LLC, either through buyouts or in the event of death. This ensures a smooth transition and safeguards business continuity Why use an LLC Operating Agreement to Ensure Legal Compliance? Let's Discover Its Assets: Why use an LLC Operating Agreement to Ensure Legal Compliance? Let's Discover Its Assets : Assets A well-crafted agreement strengthens the separation between your personal assets and the LLC's liabilities. If the LLC incurs debt, creditors cannot go after your personal belongings (like your car or house). A well-crafted agreement strengthens the separation between your personal assets and the LLC's liabilities. If the LLC incurs debt, creditors cannot go after your personal belongings (like your car or house). The agreement outlines ownership percentages, member roles, profit-sharing mechanisms, and voting rights. This transparency minimizes confusion and sets clear expectations for everyone involved. The agreement outlines ownership percentages, member roles, profit-sharing mechanisms, and voting rights. This transparency minimizes confusion and sets clear expectations for everyone involved. You can tailor procedures for meetings, voting, and management to your specific needs. This flexibility surpasses the limitations of generic state-mandated rules. You can tailor procedures for meetings, voting, and management to your specific needs. This flexibility surpasses the limitations of generic state-mandated rules. A well-defined agreement establishes a process for resolving disagreements among members, preventing conflicts from disrupting your business trajectory. A well-defined agreement establishes a process for resolving disagreements among members, preventing conflicts from disrupting your business trajectory. For single-member LLCs, the agreement can outline how ownership will transfer in case of death or disability For single-member LLCs, the agreement can outline how ownership will transfer in case of death or disability For single-member LLCs, the agreement can outline how ownership will transfer in case of death or disability Nevertheless, it`s needed to oversee some liabilities and considerations of such document liabilities Without legal assistance, an agreement will not contain your unique circumstances and ensure effective potential issues management. Without legal assistance, an agreement will not contain your unique circumstances and ensure effective potential issues management. It requires considering provisions for capital contributions, distribution of assets upon dissolution, and non-compete clauses (if applicable). It requires considering provisions for capital contributions, distribution of assets upon dissolution, and non-compete clauses (if applicable). The agreement needs routine monitoring and check-ups as needed to provide consent of all members to adapt to business needs. The agreement needs routine monitoring and check-ups as needed to provide consent of all members to adapt to business needs. In conclusion, the LLC Operating Agreement is crucial for the making of financial, management, and operational decision processes. The agreement defines the business roadmap and clarifies various procedures. In conclusion, the LLC Operating Agreement is crucial for the making of financial, management, and operational decision processes. The agreement defines the business roadmap and clarifies various procedures. In conclusion, the LLC Operating Agreement is crucial for the making of financial, management, and operational decision processes. The agreement defines the business roadmap and clarifies various procedures.

 LLC Operating Agreement: Why It's Important

The decentralized finance (DeFi) ecosystem continues to expand across multiple blockchains, offering new opportunities but also introducing major challenges. One key issue is that of fragmented liquidity - assets and trading activity spread thinly across disconnected platforms. Another threat comes from weaknesses in cross-chain interoperability - bridges that promise to connect blockchains but with security flaws that leave funds at risk. To discuss these problems and potential solutions, I spoke with Boris Povar, a co-founder, and CEO of the project. Eywa Povar brings a strong technical background to tackle these complex topics. With a degree in mathematics and programming, he has worked in crypto since 2017 after a successful career running an IT outsourcing firm. As a portfolio investor and fund manager in the DeFi space, he has direct experience grappling with risks around fragmented capital and insecure bridges. Since 2020, he has focused his efforts on developing a novel architecture for trusted and efficient cross-chain communication. Povar provides insight into the scale and consequences of fragmented liquidity and flaws in today's bridges. The interview sheds light on the roadblocks hindering DeFi's progress as well as innovative solutions in development. Povar lends both technical expertise and real-world perspective to outline a vision for the next stage in DeFi evolution. What are the problems of fragmented liquidity and insecure cross-chain communication? The problem of fragmented liquidity can be formulated as follows: Liquidity located in one blockchain is isolated and not utilized in other blockchains simultaneously. Protocols addressing this issue enable your funds to operate across multiple blockchains/protocols concurrently. For instance, Liquid Staking protocols enable participation in the Ether consensus, earning income, while still utilizing funds in DeFi. Blast operates on a similar principle, where funds in their blockchain function within major DeFi protocols in Ethereum, generating income. However, examining this problem from the perspective of bridges reveals inefficiencies. Traditional lock-mint-burn-unlock bridges are ineffective with liquidity, as they connect assets and blockchains in pairs, requiring liquidity to be added to each link. Liquidity locked in such bridges remains dormant and is utilized ineffectively; L2 bridges serve as examples. Meanwhile, the TVL of bridges is rapidly growing and has reached the total TVL of DEXes (approximately $17 billion), necessitating more efficient utilization. Thus, it can be argued that bridges exacerbate the problem of liquidity fragmentation. The issue of insecure cross-chain communication is exemplified by the Multichain protocol. Projects like Curve and Fantom relied on it for cross-chain communications and liquidity transfer. However, Multichain malfunctioned at one point, resulting in losses for these projects. Their infrastructure was entirely dependent on Multichain, and finding and integrating alternative options took considerable time. Multichain, like many cross-chain protocols, had centralized elements, making its operation heavily reliant on teams. This scenario underscores the risks associated with relying on any single bridge as critical ecosystem infrastructure, which may lead to unforeseen "black swan" events. How big of an issue are these problems currently in DeFi and crypto overall? What are the consequences? High slippages in cross-chain swaps and complex UI/UX pose challenges for the majority of users. Projects are compelled to divide their liquidity across blockchains, incurring high maintenance costs. Furthermore, most bridges exhibit centralized traits. To date, bridge hacks have resulted in losses exceeding $2 billion. At EYWA, we endeavor to consolidate the liquidity of major blockchains, enhancing efficiency without compromising security and decentralization. What initially motivated you to tackle the problems of fragmented liquidity and insecure cross-chain bridges in the crypto industry? I've been actively addressing my own challenges. With involvement in asset management and DeFi capital placement since 2020, and in the industry since 2017, I possess an in-depth understanding of the problems and risks associated with cross-chain fund transfers. Drawing on my technical background, I've meticulously analyzed bridge hacks, resulting in the loss of over $2 billion. Consequently, I grasp what's necessary to ensure the security of cross-chain communications. Moreover, I recognize the imperative of holding liquidity long-term for bridge efficiency. I'm well aware of the inefficiencies in DeFi liquidity utilization, contributing to the dominance of CEXes over DEXes. The first wave of cross-chain bridges, while experimental, merely offered a pricier service without enhancing security or decentralization. I often phrase it as: "It’s still the same CEX, just in a new package." Hence, since late 2020, I've been dedicated to developing a genuinely decentralized cross-chain protocol capable of rivaling CEXes without compromising decentralization and security for development speed and convenience. How exactly does aggregated bridge and consensus architecture provide security for transfers? Most cross-chain bridges currently employ their own messaging protocols, which often fall short in terms of decentralization and entail various risks associated with teams, regulations, and management. It's fair to say that virtually all bridges on the market require trust, leaving the entire ecosystem vulnerable to potential "black swan" events. In response to these challenges, the Eywa team, in collaboration with the Curve team, is developing a trustless bridge that relies on a consensus of the most reliable messaging protocols available. We leverage Axelar, L0, Wormhole, Chainlink CCIP, and other messaging protocols to create a highly secure solution for messaging, custody, and liquidity transfer. By combining Eywa Token Bridge smart contracts with data validation consensus, we establish an Eywa Consensus Bridge that ensures security independently of any team and enables users to retain control over bridge liquidity. When transmitting information, it will be sent in parallel to several messaging protocols based on the user's choice, allowing users to specify preferred bridges and required quorums. The bridge's smart contract in the destination network aggregates transmission results and compares them until a quorum is reached. Users can customize the level of security needed, determining the number of checks. If any protocol returns incorrect data, the transmission will be halted. Imagine initiating a cross-chain transfer of a substantial sum. Initially, your funds are secured in the bridge's smart contract. Subsequently, a cross-chain transaction is initiated, transmitted, and verified concurrently by multiple data transfer protocols. In the destination network, a specialized smart contract receives and compares responses. If consistent information is received from all protocols, the final transaction executes your transfer. However, if any bridge is compromised, resulting in mismatched data, the transaction will be aborted, allowing you to reclaim your funds in the source network. The probability of all transfer protocols being compromised simultaneously approaches zero. How does utilizing Curve’s existing deep liquidity pools enable low-slippage cross-chain trading on CrossCurve? The more liquidity available, the lower the slippages, which is an evident concept. However, to elucidate how utilizes Curve pools, I must delve into its architecture. As mentioned earlier, the issue with bridge liquidity fragmentation lies in the fact that locked liquidity within bridges remains inactive in DeFi. CrossCurve To address this, we utilize Curve's LP tokens as the foundational liquidity. Leveraging Curve's ability to exchange LP tokens within the pool as standard tokens, we generate s-tokens - synthetic collateralized derivatives - by consolidating them on one public blockchain, known as Hubchain (currently Fantom). Subsequently, we establish stable liquidity pools on Curve by connecting s-tokens of similar nature. These pools offer minimal slippage. A typical exchange transaction traverses three blockchains, involving an imbalance operation to add liquidity to the Curve pool in the source network, followed by minting the corresponding s-token to the Hubchain, where it is exchanged for an s-token backed by the Curve LP token from the destination network. The s-token is then burned, releasing the LP token in the destination network, and the final step involves an imbalance withdrawal of liquidity from the Curve pool, transferring it to the user's wallet - adding liquidity, exchanging, and removing liquidity. The greater the liquidity in the pools we utilize, the lower the losses incurred. Additionally, this architecture enables more efficient capital utilization as the liquidity from all blockchains is consolidated in one location simultaneously, rather than in pairs. Consequently, CrossCurve requires substantially less liquidity compared to its competitors to achieve low slippage. What are the main benefits to projects and developers of listing their tokens on CrossCurve? Web3 projects can list their tokens on any chain against crvUSD/Stables/WBTC/WETH/Curve LPs and trade them simultaneously across all chains for any asset. They can also receive yield provided by Eywa, Curve, and Convex on provided liquidity, attracting new users from different blockchains. Fast scaling for the utility of your token in other networks, while also reducing the costs associated with maintaining cross-chain liquidity by keeping a single pool. How does CrossCurve simplify the user experience for cross-chain DeFi operations? We utilize cross-chain ZAP transactions, condensing a large number of transactions for the user. For instance, a typical exchange involves a series of transactions across three blockchains, yet the user only needs to initiate one transaction. How will the CrossCurve yield flywheel attract liquidity providers and projects to the platform? Since all CrossCurve pools are native Curve pools, we have access to various tools for managing incentives. These include direct incentives, veCRV bribes, Convex rewards, and other vote aggregators like StakeDAO, Lobby, and Yearn. Additionally, we can create our own votemarket, accumulate Curve and Convex votes, and participate in CRV Wars. Our plan involves using bonding mechanisms to attract the protocol’s own liquidity to the main pools. The first phase of our flywheel launch will focus on direct incentives for pools, veCRV bribes, and attracting our own liquidity through bonding. Subsequently, we will introduce a DAO and our own vote market. The issuance of the EYWA token will be exclusively available to long-term holders and members of the CrossCurve DAO, thereby strengthening the token's value. Curve liquidity providers will receive enhanced yields on their LPs, and we will provide them with a seamless method to contribute to CrossCurve pools. Projects will have the opportunity to offer incentives on their pools. However, to receive additional incentives from the CrossCurve DAO and partake in their distribution, they must become members.It's worth mentioning that we will assist Curve in distributing their stablecoin crvUSD, as it is their priority. In return, they will support us with incentives by voting for our main pools. How will CrossCurve boost adoption of less liquid layer 1s and layer 2s through liquidity bridges? We are currently constructing a cross-chain liquidity core by combining the largest blockchains by TVL. Subsequently, we will integrate emerging blockchains into our system and link them to this core, simplifying the process of liquidity migration between networks for liquidity providers. What role will the CrossCurve DAO play in solving liquidity fragmentation and boosting chain interoperability? CrossCurve will function as a transport hub for liquidity migration between different chains, offering additional income opportunities for liquidity providers. They will receive a base yield for providing liquidity on the original network, along with a yield for contributing their LPs to CrossCurve pools. Additionally, we intend to serve as a launchpad for Web3 projects seeking to establish multi-chain liquidity. This will enable them to utilize a single liquidity pool that serves all blockchains. How will votemarkets and bribing systems incentivize long term alignment between liquidity providers and the protocol? Long-term liquidity providers will become members of the CrossCurve DAO, engaging in the distribution of issuance among CrossCurve pools. They will also receive platform commission income and incentives from projects seeking augmented rewards. Where do you see the main competition in cross-chain DEX space, and how is CrossCurve positioned against them? My primary competitors include projects such as Stargate, Squid, Synapse, and Hashflow. We position ourselves as a solution primarily catering to liquidity providers and DeFi power users who necessitate seamless movement of substantial liquidity across blockchains. Additionally, we address the challenges faced by Web3 founders, enabling them to reduce the expenses associated with establishing and maintaining multi-chain liquidity while broadening their access to users across various blockchains, thereby diminishing their reliance on specific blockchain ecosystems. Our key advantages include the capacity to facilitate large-volume exchanges with minimal losses, akin to Curve's renowned capability, efficient utilization of liquidity, a seamless user experience, robust security measures safeguarding funds within our bridge, lucrative farming opportunities for liquidity providers, and an attractive proposition for projects seeking to establish their own liquidity pools. What chains and assets will CrossCurve focus on supporting in the initial launch stages? CrossCurve will focus on supporting the Ethereum, Arbitrum, Optimism, Polygon, Avalanche, BNB Chain, and Fantom chains along with the USDT, USDC, DAI, WBTC, ETH, crvUSD, 3crypto Curve liquidity pools, crvUSD-USDT Curve liquidity pools, and 3crv Curve liquidity pools assets. Do you intend to partner up with other major players, DAOs and bridges? If yes, in what capacity? To construct the Consensus Bridge, we are collaborating with Curve and will engage with prominent players in the cross-chain market — L0, Wormhole, Axelar, and Chainlink — as integrators of their solutions. For liquidity building, we have partnered with Curve and other entities within the Curve ecosystem, including Convex, StakeDAO, Yearn, and Lobby, to incentivize their users. We are also collaborating with yield aggregators like Beefy. We are currently in negotiations to integrate all new blockchains that Curve will support. Among those on the list are Mantle, Linea, Scroll, zksync, BNB Chain, and others. Additionally, we plan to identify a new Hubchain, a strategic partner blockchain. To enhance scalability and on-chain performance, we will collaborate with bridge aggregators such as Li.fi, Rubic, and Rango, as well as with wallets like Trust Wallet. In the future, we aim to extend support for liquidity aggregation from other DEXes, such as Balancer and Uniswap.

Fragmented No More: CEO of EYWA Explains Fixing Spread-Out Liquidity and Bridge Security

খণ্ডিত আর নয়: EYWA-এর CEO ব্যাখ্যা করেছেন স্প্রেড-আউট লিকুইডিটি এবং সেতু নিরাপত্তা

Schluss mit der Fragmentierung: CEO von EYWA erklärt die Behebung verteilter Liquidität und Überbrückungssicherheit

No más fragmentados: el director ejecutivo de EYWA explica cómo solucionar la liquidez dispersa y la seguridad del puente

Fini la fragmentation : le PDG d'EYWA explique la solution à la question de la liquidité étalée et de la sécurité du pont

अब खंडित नहीं: ईवाईडब्ल्यूए के सीईओ ने स्प्रेड-आउट तरलता और ब्रिज सुरक्षा को ठीक करने के बारे में बताया

断片化はもう終わり: EYWA の CEO がスプレッドアウト流動性の修正とブリッジセキュリティについて説明

더 이상 단편화되지 않음: EYWA CEO, 분산형 유동성 및 브리지 보안 수정에 대해 설명

Fragmented No More: CEO da EYWA explica como consertar a liquidez espalhada e a segurança da ponte

Больше нет фрагментации: генеральный директор EYWA объясняет, как исправить разброс ликвидности и безопасность моста

Artık Parçalanmış Değil: EYWA CEO'su Yayılmış Likidite ve Köprü Güvenliğinin Düzeltilmesini Açıklıyor

Không còn bị phân mảnh nữa: Giám đốc điều hành của EYWA giải thích cách khắc phục tính thanh khoản dàn trải và bảo mật cầu nối

不再支离破碎：EYWA 首席执行官解释解决流动性分散和桥梁安全问题

As a tech that allows companies to build powerful systems and store data securely, blockchain has found , especially in the field of finance. The decentralization capabilities have also become a valuable asset in political, social, and economic areas. quick adoption Like so many young technologies, blockchain works very well on paper. In fact, blockchain technology has been reviewed from every possible angle and its future is . very promising Despite the glowing reviews, however, we have yet to experience a futuristic world run on blockchain systems. Risks often come from an unexpected source; one that is not necessarily considered when securing blockchain systems: the human factor. The human factor has prevented blockchain from flourishing. This article will look at how and why. System Building Decentralized systems are arguably the most interesting aspect of blockchain. Initially, it promised a true revolution as a financial system not controlled by banks. Human behavior, however, affects the rules and protocol configuration. Selecting or is always determined by the way humans interact with the system, which can allow people to take advantage of it. consensus algorithms security parameters While some architectures can successfully navigate the human factor—such as the , which was originally designed as a captcha mechanism in the early 2000s—there are multiple architectures that are more susceptible to external attacks. proof of work consensus For example, happen regularly as a result of asset concentration. 51% of attacks Another factor to consider is how the blockchain is managed. There are also private blockchains and several decentralized platforms—such as Hyperledger, Corda, and Quorum—but a blockchain can’t be controlled and regulated by a single authority, as that would defeat the purpose. Security And Audits Despite its efficient operation, blockchain cannot create or evolve its own security measures. During the process of development, human error can create vulnerabilities within the system. Regular and efficient audits are, therefore, vital. Ideally, every time a new string of code is written, it should be audited and tested separately and with the whole contract. But some cut corners, eager to release the product quickly. External attacks are , and the responsibility for them falls equally on the attacker and the protocol owner. You can’t prevent every attack, but there are mechanisms to contain it or stop it altogether. very common Security has to be an essential part of the whole development process. That’s where consensus audits and attack threat modeling come in. Unlike a code audit, this process involves the initial idea and possibly some block diagrams. Consensus audits review the main rules that need to be followed for a consensus to be reached. Something like passing a law or a bill in the government. Attack threat modeling follows that law analogy and shows what happens if the law is abused. By modeling such situations in advance, you can help prevent them. We encounter this all the time with HashEx, especially with experienced companies as they order attack threat modeling to be able to see in advance which types of attacks would be likely used against the architecture. Consulting during the early development stages can provide project owners with the necessary information and help them overview the scope of the work that lies ahead. There are methods to secure blockchains. All we need is to take advantage of them. Interface And Accessibility One of the primary goals for all blockchain developers is increasing the adoption of this technology. So far, it’s been a slow and painful process, mostly due to blockchain’s complexity. Psychologically, we aren’t inclined to use a system that consumes a lot of time and requires extensive education. Humans want and will always choose user-friendly options. That’s what blockchain has to become: user-friendly. Sure, it starts with a code, but it doesn’t have to be complicated. There have been many suggested uses for blockchain in commerce, healthcare, or when working with documents. In all cases, one of the main issues preventing adoption is usability. To understand this, here are a few examples that illustrate the practical applications of blockchain: • Walmart has been at the into its supply chain management, particularly in the realm of food safety and traceability. By implementing a blockchain-based system, Walmart has enhanced the transparency and efficiency of its supply chain. forefront of integrating blockchain technology This technology allows for precise tracking of food items throughout the entire supply chain, from farm to store shelves. The primary goal is to ensure food safety by quickly identifying and addressing any potential issues in the food supply chain. • Another sector where blockchain has made significant strides is in digital identity verification. Estonia's e-Residency program is a pioneering example of how . blockchain can secure personal data • In the healthcare industry, blockchain-based systems are being developed to in order to improve the security and interoperability of healthcare information. manage electronic medical records By focusing on user-centric design, blockchain can be made more accessible, encouraging adoption across various industries. What Blockchain Needs Some may disagree, but blockchain doesn’t have the best reputation today. Yes, it’s been an incredible help to many areas, but its notoriety is mostly connected to financial scams and failures of the market. The key to changing that is education. And I don’t just mean educating people about the technology and its advantages. We need to educate professionals to take over the development and management of blockchain-based systems. We have to involve it so it can do more good. And it’s most necessary to fix our previous mistakes. Maximizing the positive effects of this technology should be a priority. Blockchain can’t remain a closed field for a group of skilled experts. For the technology to truly bloom, it has to become accessible. Follow me on . Check out my . LinkedIn website Also published here

The Human Factor In Blockchain Development: How It's Prevented Blockchain From Flourishing

This is a continuation of my article on CBDC (Central Bank Digital Currency) from the “Now You Understand” series. , I looked at what a CBDC is, and how this form of digital currency can be used, how it differs from stablecoins, and why private rather than public blockchains are used to implement CBDC solutions. In the first part You can read it here ⬇️ https://hackernoon.com/now-you-understand-central-bank-digital-currency-cbdc-explanation-and-usage-part-i?embedable=true In this part, I will look at what solutions are being used in different states to implement CBDCs, take a closer look at the Brazilian DREX case study, and follow the dynamics of CBDC implementation around the world. Enjoy reading! What solutions are countries using to implement CBDC? To implement CBDC, central banks will need a blockchain infrastructure. In this section, we’ll discuss the technical characteristics of the most common blockchain platforms for implementing digital currencies. During the research for this article, I conducted a thorough analysis of different solutions and platforms. My findings show that Based on the data and sources studied, it is evident that a few select blockchain platforms will be used prominently in various countries for CBDC implementation. Hyperledger Blockchain is emerging as a dominant tool in this domain. In addition, notable platforms such as Quorum and R3 Corda are actively used in significant projects (e.g., Dunbar, Jura). The selection of these platforms is driven by their popularity and track record, particularly in facilitating CBDC implementation. Hyperledger Besu Besu is an EVM-compatible blockchain platform with additional functionality to provide privacy capabilities. It supports private smart contracts and transactions. In the corporate sector, this is a must-have for technology adoption at all stages. Privacy became possible here due to a separate set of nodes that is responsible for encrypting private transactions. The Besu client does not include built-in private key management. External tools, such as Ethereum-compatible wallets, are used to manage private keys and sign transactions. This provides a greater level of security and flexibility. Besu is a permissioned network. It allows you to list approved accounts and deny all transactions from accounts that are not on the list. It allows you to determine which nodes can connect and participate in the network and which cannot. This is also achieved by adding nodes to the list of approved nodes, if a node is not on this list it is denied access to the network. This increases overall security and access control as well. Since only selected members can participate in the network, it significantly increases throughput. Hyperledger Fabric Fabric is a private blockchain platform designed for enterprise use, with a focus on privacy. It was initially developed by IBM and was transferred to the Linux Foundation in 2015. Unlike Besu, Fabric is not an EVM-compliant platform and has a different architecture, smart contracts are called chaincodes which are developed using , JS/TS, and . Go Java Fabric architecture includes a special type of node that is responsible for transaction processing, computation, and state management, they are called endorsers/committers. Another type of node called Orderers is responsible for reaching consensus, sequencing transactions, and placing them into blocks. For a higher level of privacy, another element called channels is implemented. Channels are represented as subnets in which only participating nodes have access to chain codes and transactions, while participants outside the channel are unaware of their existence, providing a high level of privacy and confidentiality. This functionality can be especially useful when there is a requirement to separate several directions and isolate them from each other. In Fabric, private transactions are also possible through direct P2P communications. In this scenario, only the hashes of the input data of the transaction are shared with the Orderers nodes and written to the ledger along with the transaction. Fabric supports pluggable consensus mechanisms, which means there is flexibility to choose the most suitable option for specific challenges and requirements. As Fabris is a private solution, this also means that a node in this network can only be started with the permission of authorized entities, which restricts the network participants. Hyperledger Iroha Launched in 2019, Iroha is a private blockchain platform that is also focused on enterprise use. The difference is that it has a simpler design and is easier to integrate thanks to its modular architecture. It also supports smart contracts. This platform is primarily performance-oriented with its own fault-tolerant consensus algorithm under the hood. It provides high throughput and low delay in transaction processing. A node can only be launched on this network with the permission of authorized entities. On this platform, Cambodia launched Bakong, a project controlled by the Central Bank of Cambodia, which is designed for mobile payments and banking. There was a problem with the coverage of banking services, and this project solved that problem by allowing all citizens to open an account and make cashless and secure payments. And for banks, it opened up the possibility of interbank transfers at a lower cost. This project is not entirely a CBDC, although it is administered by the Central Bank, but rather a tokenized deposit system. Quorum Quorum is an enterprise blockchain platform that is based on Ethereum but extended with functionality customized to the specific requirements of corporate clients. The platform was founded by J. P. Morgan Chase in 2016. In 2020, Consensys bought Quorum and now supports and develops the platform. The special feature of this platform is that it has a built-in privacy functionality, which opens up opportunities for corporate use. For example, there is the option for private transactions. This is very important compared to an open network because when we transfer money, we don't want anyone to know about it. The control of this platform is based on consensus mechanisms which assume that only selected participants are allowed to participate and maintain control of the network. For example, governance may be centralized at the Central Bank. Such a mechanism not only consolidates power in the system, but also provides a number of benefits, such as increased throughput and transaction speed. This is achieved by the fact that the number of nodes to reach a consensus between is minimal and limited. There is no need to wait for a large number of participants to agree. Unlike Ethereum, Quorum has zero gas costs, which means you don't need to pay for gas for transactions. As Quorum is based on Ethereum, it supports smart contracts in Solidity. Smart contracts open up the possibility of creating their applications, e.g. by commercial banks with permission from central banks. Smart contracts in Quorum can be as private as transactions. Similarly to a regular contract, for confidentiality reasons, it is necessary that they are not available to anyone. When we buy or sell a property, we don't want anyone to know the terms of the transaction and its participants. Smart contracts are deployed on the blockchain and are always available for interaction, the code is executed when called, so there is no need for a third party. For example, when we make a transaction, we have to wait for a third party, such as a bank, to execute it. In the case of smart contracts, we have no such need because everything is done by the executable code. Such interaction is always available 24/7, unlike standard organizations. They are also an excellent way to tokenize assets or access rights. Corda Corda platform is based on distributed ledger technology (DLT), but it is not a blockchain. That's why it's different from all the others. This platform is fully focused on privacy and by default all transactions are private. It does not have a global shared ledger and only supports transactions in which only counterparties are involved. Transactions are only related to bilateral or multilateral agreements between counterparties. Here each node maintains its own register of transactions, where they are linked to each other and complete in real time since there is no blockchain. But in this case the issue of double spending and others arise. Here this is solved by installing a notary which is a third party and controls the validity of transactions. Notary is a separate set of nodes and the level of decentralization is directly related to Notary. The model is based on strict confidentiality and each node must prove that it has been validly connected to the network using a certificate from authorized members. The signature capability here exists only on the nodes. Each application here exists only in the nodes of the network as well as the ability to sign transactions. This is significantly different from the standard Ethereum model where signature control is maintained by the client wallets. In fact, they simply run the process and control its execution. Here these applications are called CorDapp. : Drex (Digital Brazilian Real) Example of a CBDC implementation Brazil has launched its own CBDC called Drex (Digital Brazilian Real) in pilot mode on the Hyperledger Besu platform. As we know, it is an EVM-compliant blockchain, which means that it supports smart contracts in Solidity. The control architecture of the network is structured in such a way that it is centralized at the Central Bank and therefore managed completely privately. A node can only launch on this network with the permission of the Central Bank. End users can only have custodial wallets managed by an organization that has been authorized by the Central Bank, such as a commercial bank. There are retail and wholesale forms of CBDC. The wholesale form is intended only for high-volume transactions, such as between banks, cooperatives and possibly with the participation of large corporations. The retail form is designed for payments and transfers between individuals and businesses of any size and can be used for everyday financial transactions in any value range. In this implementation, CBDCs are smart contracts on Solidity ERC-20 standards, there are two main ones: RealDigital and RealTokenizado. The main token is RealDigital, which is controlled by the central bank. Other participants in the system, such as commercial banks and other financial institutions control their own token, RealTokenizado, which actually extends the RealDigital contract and its functionality. RealTokenizado is used to manage deposits and accounts. RealDigital itself stands as a reserve for all tokens of other participants. As we have different ERC-20 tokens for each participant they cannot be transferred directly, for this purpose swap contracts are used additionally. Therefore, when different tokens (RealTokenizado) are transferred between participants, it looks this way: RealTokenizado tokens (of one participant) are burned from the sender, RealDigital tokens (represent a reserve) are transferred from the sender to the receiver and RealTokenizado tokens (of another participant) are issued to the receiver. In this architecture there are also roles responsible for issuing, burning, moving and freezing funds. It is also important to say that participants, such as commercial banks, operate through a special account established by the Central Bank and cannot independently issue or burn RealTokenizado tokens. Stages of CBDC implementation worldwide In the first half of 2021, only 74 countries were interested in CBDC. Of these, only 3 decided not to develop this direction, 28 countries were in the research stage, 14 countries were in the development stage, 18 countries launched their own CBDCs in pilot mode and 1 country completely launched. By mid-2023, the picture has changed significantly, from the key parameters - now 130 countries have expressed interest, of which 46 are in the research stage and 32 are in the development stage. Pilot mode has been launched in 21 countries and 11 countries have fully launched. It is important to note that these 130 countries that are expressing interest in CBDC represent 98% of the world's GDP. From this we can conclude that this direction is of interest to the majority of countries in the world and has huge potential, and the active growth in the rate of research and development indicate that it is likely to be realised on a grand scale. The world situation at the moment is as follows: My opinion on CBDCs Even though many crypto enthusiasts believe that current CBDC implementations by central banks are not in line with the basic principles of the crypto community, I suppose that CBDC implementations should not be measured by public blockchains. CBDC implementations most often have fully centralized control, which crypto enthusiasts are against, but it should be understood that CBDCs cannot and should not be implemented otherwise. This is due to many considerations, including privacy and legality of transactions.  Yes, such a centralized implementation loses some of the advantages of public blockchains, but at the same time, it solves more important country-specific issues and reduces risks. Conclusion There is a significant global interest in CBDC implementation, which indicates a high promise of changing the traditional system towards CBDC and tokenization of assets. For CBDC implementation, private solutions are used that provide privacy control and centralized control over the Central Bank. They also support a high level of programmability, which makes it possible to create your own rules for CBDC. Unlike public networks, there are no transaction fees. Because transactions occur according to programmed rules - there is no need for a third party to verify them, and therefore these solutions are available 24/7. Control over the private network is limited to selected members and there is no need to wait for the majority to agree as in the case of public networks. CBDCs enable the tokenization of assets and property, optimizing the costs of the current registry infrastructure and increasing security, speed, and cost of transactions. Smart contracts in CBDCs open up opportunities to automate many processes and increase their security, including cross-border payments. Digitizing money makes it more transparent, efficient, controllable and accessible, removing vulnerabilities and inefficiencies in the current infrastructure.

Now You Understand: Central Bank Digital Currency (CBDC)—Explanation and Usage, Part 2

CBDCs have been discussed quite a bit in recent years, and various countries are exploring the possibilities of implementation. You may have heard or read about this digital currency, but do you have a good understanding of how CBDC is structured, how it can be used, and what impact central bank digital currency will have on the future of finance? Welcome to my Now You Understand article series, where I share my expertise to explain the most complicated blockchain and web3 topics. This is the first part of my article on CBDC, where I will cover what it is, the use cases, and the solutions used to implement it. What is CBDC? Central Bank Digital Currency (CBDC) - a digital form of national bank money that is created, controlled, and maintained by the central bank. It is legal tender and is the same central bank debenture as ordinary bank notes. CBDC is operated by a digital ledger that might or might not be a blockchain. This provides faster and more secure transactions between banks, institutions, and individuals. Central banks control the issuance of CBDCs and stand as guarantors of this form of money as compared to cryptocurrencies. CBDCs now can take the following forms: Retail is used for settlements between individuals and legal entities, is designed for simple payments, and represents a digital form of currency. Wholesale is used for interbank payments as a new infrastructural solution. CBDCs can also represent digital assets, they are also registered in a digital registry, which can be distributed or not distributed. CBDC is a major step forward in the digitalization of money and the economy as a whole,  increasing its transparency, security, and efficiency, including the automation of many processes and the reduction of transaction costs. CBDC: Use Cases CBDC is implemented mainly on platforms based on distributed ledger technology (DLT) with support for smart contracts (applications). That gives us many areas of usage and makes this implementation of a digital form of currency really useful for the financial system. Due to the platform’s support for smart contracts, it extends CBDC beyond just digital currency to a programmable form of currency. Smart contract support allows you to deploy programs that interact and operate with digital currency. For example, when we execute a property deal, we need someone to check the deal for compliance, approve it, and register it. In the case of CBDC, we do not need a third party to do this, we can just implement a smart contract, the logic of which will be similar to the logic of the deal. For instance, to control that one side owns the property, the other side has paid the declared value, and then makes the transfer of this property, as an option in the form of a token. In this way, we can automate the majority of transactions with almost any property, which significantly increases their availability, speed and performance. It also removes the workload from the infrastructure that is created for deals, cutting out the need for intermediaries and thereby reducing transaction costs. Tokenization is the process of converting rights to assets or property into digital tokens. Exactly it allows to be fully digital and automated with the use of smart contracts. It has been researched that the cost of clearing and settlement of securities for the Central Banks of the G7 countries is more than $50 billion per year, due to the resource costs of asset transfers and account reconciliation. A DLT-based CBDC successfully solves the problem of inefficiencies and vulnerabilities compared to the current infrastructure. CBDC is natively digital and does not demand the expensive and labor-intensive reconciliation currently required for e-commerce and cross-border payments. It also allows to optimization of the operation of any registry that is responsible for storing records of rights to property or assets. For example, DLT technology can replace and improve the work of registries of movable and immovable property, securities such as stocks, bonds, etc. It also makes it possible to make deals available 24/7 by eliminating the need for a third party to determine the availability of transactions. Digital property/asset transactions increase the accuracy and security of transactions. Offline payment technology, which provides access to the financial system in areas not covered by banking services and allows transactions to be made without access to the Internet, is currently being actively researched and realized. We can see that CBDCs move the financial system into a digital form, which opens up many possibilities and optimizes the operation of the system as a whole. Thanks to this, CBDC has direct control over the money supply, simplifying the distribution of state benefits, and improving the control over transactions for tax control. Thus, timely payment of taxes or payment of bond coupons can be automated. The implementation of CBDC also allows for reduced costs and increased availability of cross-border payments, including reducing credit risks by providing payment versus payment settlement. CBDC vs Stablecoins: what’s the difference? There are several types of : fiat-backed, cryptocurrency-backed, commodity-backed and algorithmic. In this comparison, we will focus on the first type - fiat-backed ones, because they have more in common with CBDCs and are the most popular. Examples of this type of stablecoins are Tether ( ) and USD Coin ( ). stablecoins USDT USDC The principle of Stablecoins is that organizations issue tokens based on the reserves of traditional money in their accounts. That is, in this case the issuance and control of such tokens remain with private institutions and they are not directly controlled by Central Banks. While CBDC is a form of national currency, their issuance and control is owned by Central Banks, which provides higher security. Due to such regulation CBDC can ensure compliance with tax policy, while in stablecoins do not. It is also important to note that stablecoins use private money as collateral, while CBDCs are backed by government-issued money. What is the difference between private solutions and public blockchains ? Public blockchains are primarily defined by the fact that they are open to the public. That means anyone can join and participate in the network. A popular example of public blockchains is Ethereum. The consensus mechanism means that such a network is managed by the majority. In particular, transactions are verified and included in new blocks. They are completely open and transparent, everyone can see all transactions and balances of any accounts. In order to complete a transaction in a public network, it is necessary to verify and confirm the agreement of the majority of participants, which involves commissions, which are the motivation, as well as a longer waiting time due to the fact that it is necessary for the majority of nodes to reach an agreement. Among the advantages of this solution, we have full transparency and no need to rely on a single control structure due to the high decentralization of the network, which ensures that no single entity controls the network. A private network is closed and restricted to authorized participants who have full control over the network and transactions on it. Private solutions allow centralized control over the network and also enable private transactions and private smart contracts. This solves privacy challenges that are very important for governments and corporations. Private solutions consensus mechanisms involve a very limited number of participants who verify and approve transactions, so transactions are much faster because they do not require majority verification. They also do not need such a concept as native currency and there are no transaction fees. These solutions appeal to governments and companies because of their centralized control and confidentiality solutions that also allow them to control the legality of their operations. Guarantee of this network are their participants, for example, governments and corporations. Examples of this type of solutions are Quorum, Corda, Hyperledger Besu etc. CBDC: Why use private solutions? There are several key reasons why public solutions are not suitable for CBDC implementation. Public cryptocurrencies mean an open market and they are subject to significant price movements, which entails heavy risks for both the government and ordinary users. High volatility: This makes it difficult to use as a payment method, as changes in value can be in the tens of percent. In the case with private solutions, the Central Bank is the guarantor and has full control over the digital currency. CBDC is a form of currency rather than a cryptocurrency in its traditional meaning. In public solutions, all data is publicly available. Open data potentially brings risks for directions in which this is a key factor. In private solutions, it is possible to control privacy issues through private smart contracts, private transactions, and restrictions on network participants. Privacy considerations: With public solutions, accounts and funds are under the control of the users themselves or organizations to which the users have delegated control.  In the case of private solutions, account control is usually performed by authorized entities. Account control:

Stories, News & Mentions about QUORUM

Quorum’s Stories on HackerNoon

Quorum's News & Mentions