for a normal user to run a full node on his PC?
If we define a "normal user" as Average Joe, who would like to just transfer some tokens or even deploy a smart contract, then there are not many reason why such a user would want to run a witness node.
But there are some:
If you are a developer/service provider (like exchange, block explorer) and you need ...
Blocks on EOS are produced every 500ms (milliseconds) by Block Producers, or BPs for short (sometimes known as Witnesses or Delegates).
Unlike Bitcoin and other PoW coins, EOS uses DPoS (Delegated Proof of Stake) which allows for extremely fast and consistent blocks by scheduling them to individual BPs. They do not vary in time like Bitcoin, unless a BP ...
Blocks are produced turnwise by so called "block producers" within the Delegated Proof of Stake protocol. This prevents all "miners" from rushing for the right hash like it is done in Proof Of Work. The turn duration is 0.5 seconds for EOS but may be different on other EOSIO chains.
Maybe this article about DPoS helps you understanding.
Aside from monetary incentives, the primary incentives for running your own node would be speed of access to the information in the block, and the ability to run custom plugins that are needed to power your application.
Since any node that runs will replicate all of the blocks as they are produced, accessing a local node will allow your application to query ...
Every chain can choose to implement this however they like.
On the EOS Mainnet
The round robin is deterministic, and cycles alphabetically through each of the block producers.
This actually causes occasional blocks to be missed due to latency, so there is a plan to introduce a latency-based cycle, where the BPs are placed next to their nearest geographical ...
Last irreversible block (LIB) is the way of providing BFT finality assuming at least 2/3+1 honest producers. However, a single confirmation from a BP is not sufficient proof to contribute to making an irreversible block--this would mean that when the last of the 2/3+1 BPs signs the block, it's immediately irreversible. However, by the time the other (honest) ...
On GitHub, Dan Larmier discusses the issue with the older DPOS 2.0 algorithm. To summarize, the old algorithm allowed a situation where, in a situation where there is a small network interruption, a producer could end up producing a block that inadvertently confirms a block that he hadn't previously seen. This occurred because producing a block on a chain ...
The network would indeed be in trouble if over 2/3's of the Block Producers are corrupt and collude together.
However, this is quite a big if statement, especially when compared to Proof of Work Blockchains like Ethereum or Bitcoin where only 2 or 3 mining pools would have to collude to achieve a 51% attack and control the network.
If any one Block ...
There would just be blocks missing at those time points, and the next BP will build on top of what they know to be the block of highest height.
Relevant section from the whitepaper:
The EOS.IO software enables blocks to be produced exactly every 0.5 second and exactly one producer is authorized to produce a block at any given point in time. If the block ...
Each Node in the Network adds a list of peers it communicates with to exchange data.
When a transaction is sent to a node, it is passed on to the peers and this way broadcasted to the entire network of producers.
Any event (action) that occurs on an eosio chain is at least a part of a transaction. The transactions are sent to a node that either belongs directly to a block producer, or will be forwarded to one. When sending transactions, resources are used up and can not be reused for 24 hours. These are CPU and NET bandwidth, and possibly RAM. In order to access ...
If a transaction is introduced in a block that never achieves 2/3+1 confirmations, it means there's likely a fork where at least 1/3 of the BPs are building blocks on. In this case, the blockchain is forked, and the fork with more BPs will be faster and thus will become the longest chain, where honest BPs will build on. Neither of the forks will ...
Even if it's possible, it wouldn't matter. There's mostly more than one valid block.
Fork-db tracks all different valid reversible blocks producers agreed to. Longest Chain wins.
That's why it takes some time until a block is irreversible.
Apart from the official Technical Whitepaper V2, followings are the few documents which were released even before the EOS mainnet launch:-
EOS: an Introduction: This describes about the way to reach DPoS consensus mechanism.
EOS Multi-signature: This tells you about how to ensure an account (user or contract) with multi-signature feature.
EOS: Explanation ...
Blockchain data comes in the form of transactions.
By design, each transaction must bear one or more signatures of the parties involved.
The signatures use modern cryptography.
This means the probability of one party (the rogue node) forging a signature of another (a legitimate user) is too slim to be realistically considered.
A block producing node sends ...
AFAIK, if a block producer fails to produce a block, the next BP takes over after a timeout. If a BP fails to produce blocks over a certain amount of time, he can be removed from the BP list by other BPs
EOS requires 15/21 of the producers to sign a block in order to finalize it. Once 15 producers have signed a block the block is deemed irreversible.
Byzantine Fault Tolerance is added to traditional DPOS by allowing all
producers to sign all blocks so long as no producer signs two blocks
with the same timestamp or the same block height. Once 15 ...
From the docs, to register yourself you can use $ cleos system regproducer:
$ cleos system regproducer
account TEXT - The account to register as a producer
producer_key TEXT - The producer's public key
url TEXT - URL where info about producer can be found
location UINT - Relative location for purpose of nearest neighbor scheduling