29

The protocol defines a voting mechanism to dynamically add new signers and remove existing ones. In Geth this can be controlled via the clique.propose(address, authorized) method (clique_propose for remote RPC calls). To authorize a new signer, existing ones can propose it via clique.propose("0x...", true). When more than half the signers proposed it, the ...


14

PoA in Aura consensus engine of parity defaults to 5s, which has been tested to run with good stability. PoA network runs one such infrastructure. I have tested for a 1 sec PoA using aura running across 4 different geographical regions. This is the minimum possible and one that I have successfully tested :) Stability testing across more regions is still in ...


10

It's a joke. However, Ethereum does eventually plan to move to Proof of Stake, which is intended to replace mining.


10

I'm not an expert on this Quorum world. But as i've read, the main difference between the three mechanisms you mentioned is the % of BFT (Byzantinism Fault Tolerance). BFT is defined as: Byzantine fault tolerance (BFT) is the dependability of a fault-tolerant computer system, particularly distributed computing systems, where components may fail and ...


8

There are different algorithms for Proof of Authority. For instance Parity's Authority Round is essentially round robin, where as Rinkeby's version is more complicated. Proof of Authority is not well defined enough to list specific attacks, pick an implementation. I think an important thing to keep in mind with Proof of Authority is that since the parties ...


6

Rinkeby is maxed out for its given block parameters - the transaction capacity depends on the gas limit of each block, and how fast blocks are issued on the network To improve transaction capacity you need more gas per second - either by increasing 1. or decreasing 2. See here Block gas limits are the maximum amount of gas allowed in a block to ...


6

Since some moderator decided to delete the only answer to this question here it is again: I do not have time to summarize it. Good question! I don't have an answer but I do have a link that might be worth reading In this paper we derive the functioning of two prominent consensus algorithms for permissioned blockchains based on the PoA ...


5

There are a few very detailed attacks explained in this Github EIP 225


5

Clique commands Sealer on a PoA is like a miner on PoW. You start a sealer with geth --mine --unlock "0xa132432bf" with a genesis using the clique consensus. The initial sealers are defined in the genesis block. list sealers clique.getSigners() list propositions: clique.proposals discard a proposition: clique.discard("0x1234234234234") add a new sealer: ...


4

The above answers say to type clique.propose, but they do not say where. You must attach to geth.ipc and then you can use the clique.propose("0x...",true) command. You might be able to specifically enable clique through the rpc command as well.


4

No actual consensus mechanism is used. Some nodes/keys have the right to sign blocks (configured in the example json you see at https://github.com/ethcore/parity/wiki/Proof%20of%20Authority%20Chains ), others don't. As the text says, this is only for demo/development purposes. An actual consensus mechanism will need to be plugged in later.


4

All the details are documented here: https://github.com/ethereum/EIPs/issues/225 In short, the facts for a system with N sealers: every block has a preferred sealer (in-turn signing), which will set the block difficulty to 2 if the preferred sealer does not sign the block, other sealers can jump in (out-of-turn), but they can set the block difficulty only ...


4

eth.coinbase has to point to the sealing account. If you want to remove again the second account, both accounts will have to propose the removal. You always need 50% + 1 vote, which is 2 for 2 accounts.


4

Solution Insert a special middleware in web3.py to handle geth-style proof-of-authority, like this: py> from web3 import Web3, IPCProvider # connect to the default geth --dev IPC location py> w3 = Web3(IPCProvider('/tmp/geth.ipc')) py> from web3.middleware import geth_poa_middleware # inject the poa compatibility middleware to the innermost ...


4

Proof of authority relies on a certain set of trusted nodes, known as "authorities" who are specifically granted the ability to secure the blockchain by verifying transactions and creating new blocks. Validation of the transactions in new blocks by other nodes is done exactly the same as proof of work. Since this consensus algorithm depends on trusted nodes,...


4

According white papaper of bitcoin - In Bitcoin or for any public blockchain privacy is maintained by not exposing which public key is associated to which user. So users can participate in the blockchain network without disclosing their identity. In PoA networks all the authorities need to disclose their identities while participating in the network. In ...


4

This paper addresses detail comparison of Aura, Clique and PBFT. The key difference in terms of latency according to this paper is : In Aura, each block proposal requires two message rounds: in the first round the leader sends the proposed block to all the other authorities, in the second round each authority sends the received block to all the other ...


4

Take care, the gas target and limits are in Mega-gas. The default is 7.5. Your 94000000 is actually 94 * 10^12 gas, which is semi-infinite. To get 94M, just specify 94. A good rule of thumb imho is to stick to the amounts mainnet can handle (8M). Most clients require 100-200ms to crunch through an average mainnet 8M gas block. If you raise the gas limit to ...


3

Adding a new node as sealer is simple as calling: clique.propose(<NEWSEALER>, true) You will need 50% + 1 votes. See How to add new Sealer in Geth 1.6 Proof of Authority? for more details. For the details on the specification see EIP 225 - https://github.com/ethereum/EIPs/issues/225


3

be it a PoA, PoW or PoS chain you want to build, the main point about the timing is for your nodes to be able to synchronize. If your network is private and you can ensure your network to have nodes with huge broadband and resources then you can decrease largely the blocktime. It all depends on the infrastructure your network relies on. If your different ...


3

I have figured this out. I was not using an --engine-signer, so no one was sealing the transactions. Once I specified this flag, I got an error saying the account was not associated with the specified chain. Although I seeded accounts on the chain with ether in the genesis, this is not the same as having accounts on Parity itself. Thus, I needed to set a --...


3

There is a Demo-PoA-tutorial which demonstrates how to setup a PoA network of two nodes.


3

You need to map the external/public IP of your VM to its internal interface. You can use curl ifconfig.co or curl -4 http://l2.io/ip to get the external ip of your machine and set it for your session sudo ifconfig eth0:0 $(curl ifconfig.co) up be sure that you don't have --ui-no-validation option. Here's a reference https://github.com/paritytech/parity/...


3

not really sure about it, but in my opinion the difference is small: In a PoA System you got Sealers and Signer - Nodes. Sealer are predefined in the genesis Block. So A Sealer Node is without a vote of the network allowed to mine/generate new blocks. If you want after a couple of time add new "Sealer"-Nodes, you need to add signers-Node. A Signers Node ...


3

As far as I know, JPMorgan's Quorum is ready to use with quite guarantees (which doesn't mean that it couldn't be improved or stuff like that). Think about that, Quorum isn't more than the Raft Consensus Algorithm but hoarding control about some Byzantinism, not all of them because on a private/permisioned blockchain, you can asume that not all of the ...


2

Parity supports the Tendermint consensus engine (experimental). You can use it to run a private PBFT-based network, i.e., by adding the following to your chain configuration: "engine": { "tendermint": { "params": { "gasLimitBoundDivisor": "0x400", "validators" : { "list": [ "...


2

From what I can tell, you're using two internal ip spaces. They will not talk to each other unless its on the same network. You should bind the public ip or replace the interface with interface star.star.star.star which will bind to all ip's on the host. You can test once you restart by trying telnet to the port. Also, where you have azure-public-ip, use ...


2

Have you created any sealer accounts prior to creating the genesis file? if not, create at least one sealer account first by running the following: geth account new --datadir /path/to/your/custom/datadir Note down the address this generates, then when you run puppeth you can add this address into the pre-defined list of sealer accounts during the genesis ...


2

Simply unlock your account with personal.unlockAccount(eth.accounts[0], "Password", 86400) Note: The last parameter is time to leave account unlocked in seconds. Then, start the mining miner.start();


2

The OP states they are using parity, which I had missed initially. But just for general info, here is the process for geth users on a PoA network. Use clique.propose('....') You have to create an account for the new node using geth --datadir ... new account Then add clique.propose(..) to a majority of the nodes. Try all to be safe.


Only top voted, non community-wiki answers of a minimum length are eligible