Hot answers tagged

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

Pantheon (0.8.1) has no account management. It will only create a server private key, which is stored unencrypted in datadir/key. This key will also be used as the sealer account in Clique-PoA. Hence the public address stored in extraData in genesis.json has to correspond to this private key.


3

yes, have a look at my current question: parity TPS optimization - please help = I could not really accelerate parity yet. For now, geth looks MUCH faster. Feel free to run your own benchmarks, it is easy with chainhammer & chainreader. Please report back what you find out. Thanks.


3

Since nobody has provided an answer so far, I'll try to summarize my research on this. If someone is able to provide a better "story", I will switch the checkmark to it. After reading the pBFT paper from Castor/Liskov, I believe that 66,6% + 1 rule from pBFT also applies for Clique too. Hence, 50% + 1 is not enough to be sure that the transaction can not be ...


3

Performance: The transaction throughput is limited (among other things) by the block size. By how many transactions one can fit in a block. Proof of Authority is a centralized consortium chain and can handle potentially hundreds of thousands (or millions) of transactions per second because the scalability is not bounded by consensus on what is the correct ...


3

As far as I know, plasma is trying to minimise storage and logic. With a UTXO-based sidechain, the bitmap can directly represent txs bit by bit. They do mention in the white paper that it is possible to still do it state-based but it would increase the logic behind it.


2

A bucket list is a list of things you'd like to do before you die, such as getting a private PoA network up and running. A bucket limit is an upper bound for the number of peer IP addresses that your client can handle in any given "bucket" while running its peer discovery mechanisms. From the code, it looks like the limit is set to 2 peers from the same /...


2

clique API is a geth specific extension. You can enable this with --rpcapi clique Then you can send the corresponding JSON RPC calls. E.g. curl -X POST --data '{"jsonrpc":"2.0","method":"clique_getSnapshot","params":[],"id":1}' http://localhost:8545 curl -X POST --data '{"jsonrpc":"2.0","method":"clique_getSigners","params":[],"id":1}' http://localhost:...


2

I don't know if thats what you are looking for (try to be more explicit on your questions). But as far as I understood, to test a PoA consensus yo have this options: Kovan (The official PoA testnet) where you can test your contracts or whatever you want. If you want to test how the PoA consensus works and create a private PoA ethereum blockchain, you can ...


2

Non-mining sealer node which is also called non-validator nodes is just deployed so developers and users can connect with these nodes and can interact with the blockchain. As sealer nodes are critical so this is not opened to all. Few non-validators nodes are also good to run so that other non trusted users can connect to our network with limited access.


2

According to an abstract of this paper: The analysis advocates that PoA for permissioned blockchains, deployed over the Internet with Byzantine nodes, do not provide adequate consistency guarantees for scenarios where data integrity is essential. We claim that PBFT can fit better such scenarios, despite a limited loss in terms of performance


2

The UTXO model is for starting on the Minimal Viable Plasma. This is so that it is much easier to implement, than an account based model like in an ethereum chain, in terms of security mechanism of plasma, which I think is what the MVP is focusing on. Yes, the idea eventually is to implement general state transitions on the child chain like on ethereum, but ...


1

In addition to the above, it depends on which flavour of PoA you are running. Clique has determinstic finality and is works off GHOST (Greediest Observed Heavy Subtree). So depending on your trust model, you might want to wait a couple of confirmations. Aura on the other hands provides finality after a majority vote i.e greater than n/2 validators have ...


1

I guess that depends on your network layout and your level of trust. If it's a big and distributed network there is bound to be some latency and you will get sub-chains. But if it's small and trusted you will get a lot less sub-chains. I guess PoA chains are typically quite small (maybe?). The amount of confirmations you want to wait for is up to you. In ...


1

Clique extradata field, used to define PoA validators/sealers must match the following format: First part: 32bytes vanity, meaning whatever you want here since it's expressed as an hex string (64 chars long as one byte is 2 chars), here in the example it's just zeros. Second part: concatenated list of sealers/validators nodes addresses. Each address written ...


1

If you're talking about geth Clique PoA, then ether used to pay gas costs is not burned, but collected by the sealer. So basically it circulates. See https://github.com/ethereum/EIPs/issues/225#issuecomment-428911386 Ether doesn't vanish from the system. It just gets redistributed. Any fees paid by users are going fully to the signers, so they themselves ...


1

data = { "jsonrpc": "2.0", "method": "eth_sendTransaction", "params": [{ "from": w3.eth.defaultAccount, "data": Web3.toHex(bytecode), "gas": Web3.toHex(8000000), }], "id": 420 } Ok, gas should be added to the params, I added it to data, that did not work


1

If it is a private blockchain there is no rationale to use proof-of-work or proof-of-stake. Because it is private you control the money pool and access 100% and proof-of-authority is the only sensible choice, because you are already the authority in the first place. Because proof-of-authority is "decide by the authority" and there is no economic games and ...


1

Before you connect to MyCrypto application you have to alter your node configuration to enable cors: [rpc] port = 8540 apis = ["web3", "eth", "net", "personal", "parity", "parity_set", "traces", "rpc", "parity_accounts"] cors = ["all"] In bottom left select "Change Network" and then "Add custom node". In the pop up from "Network" select "Custom" at the ...


1

AFAIK, ethereum will reorg and choose the chain with more difficulty. in the PoA, if the signer is in-turn the difficulty is 2 and 1 when out-turn.


1

You can consider a transaction 100% final, if there is an upper limit to network delay between nodes and 51% of validators are honest and have signed your block. If you can't guarantee 51% honest validators, you need 100% of validators signing your block, 66% of them being selfish and 1 being honest.


1

When you have 3 signers, at least 2 have to be online and have the eth.coinbase account unlocked to be able to continue sealing new blocks. Otherwise the sealing process stops with "Signed recently, must wait for others". If you're sure that your sealers are online, then the only logical explaination is that your account unlock has ran into a timeout (...


1

From my experience, "race conditions" can still happen in PoA. In your example: If we are assuming, by node1 sealing the block first that it is the block that is accepted into the canonical chain, then node2's block would then become an uncle. user2's transaction would be in this uncle and therefore not appear in the canonical chain. However, since you ...


1

This issue has been solved by the go-ethereum team. @karalabe: The transaction should propagate across the network at the same time. It however is not included in the current block, because the block currently being mined is already finalized. It's expensive to recreate a new block every time a new transaction pops up. And in the case of ...


1

I think someone have access to your node and spam it with transaction to his address from your unlocked accounts. This empties your balance and spam so much your node with tx that it runs out of memory. The accounts spamming your node are : 0x7097f41F1C1847D52407C629d0E0ae0fDD24fd58 0x6e4Cc3e76765bdc711cc7b5CbfC5bBFe473B192E ...


1

The command to deploy your contracts to the Parity network would be truffle migrate --reset --network development. 'Development' is the name of the network you specified in your truffle.js file. It looks as though you're using truffle migrate --reset.


1

No, there's no good way to get this sort of information about the current block in Solidity. An idea that may be more practical is to call the function in the next block, and have it find the price for the previous block


1

Check on your genesis file what accounts are funded. When you create it you need to have some funded accounts (sealer nodes, faucet etc). You can then get their private key from the keystore and "guess" the password. then you can import them into a wallet and use it to transfer some ETH to some other account.


1

1 ) If you set gas price to 0 transactions will not have any cost(ether cost), in PoA there is no reward for making a block, ether is either given from initialization or not given at all. 2 ) If you set gas price to 1 you will end up in short after some time ( long probably ) but since no reward is given, there will a problem. A way of overcoming that ...


1

In the genesis file there is a gasLimit field that is used to set the intial gas level but like you're seeing this will move up or down with every block. These values are only applicable to the genesis block. But you should be able to use the --targetgaslimit flag to set a value that the gas limit will move towards.


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