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

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

Quorum

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

QUORUM

quorum.us

-- employees

Since n.d.

COMPANY RANKING

QUORUM

EVERGREEN INDEX #8877

Representing this company? Click here to claim and customize this page!

Quorum WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

QUORUM

quorum.us

-- employees

Since n.d.

COMPANY RANKING

QUORUM

EVERGREEN INDEX #8877

RELATED COMPANIESRANK

STORIES ABOUT QUORUM

Representing this company? Click here to claim and customize this page!

Quorum WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!