Ethersocial Consensus and Algorithm

A reader sees a block time and reward on a coin listing and wants to check them. The ethersocial algorithm is Ethash-style proof of work inherited from Ethereum, so block time and reward are protocol parameters. They can be checked against block timestamps.

This page covers the rules behind the ethersocial coin. It explains how consensus works, how to measure block time yourself and where reward figures should come from. Anyone planning to run hardware can go on to how to mine ethersocial.

Common misunderstandings about the algorithm

Most confusion comes from treating three separate things as one: the mining algorithm, the consensus rules and the economic parameters. The algorithm decides how a miner proves work. The consensus rules decide which blocks every node accepts. Block time and block reward are parameters set inside those rules. A quoted figure for any of them is only as good as the document it comes from and the chain data that confirms it.

• “The algorithm sets the block time.” Proof of work defines how a block is found, not how often. The interval comes from the difficulty rules in the client, so it has to be measured from the chain rather than inferred from the algorithm name.
• “A block explorer shows the rules.” An explorer shows what happened: heights, timestamps, miners and rewards paid. It is evidence for checking a rule, not the rule itself.
• “Ethereum documentation describes Ethersocial.” Ethereum documentation on Ethash and proof of work explains the mechanism that Ethersocial’s client inherits. Ethersocial-specific values, such as its reward schedule, belong to the project’s own whitepaper, roadmap and code.
• “Any explorer works for any chain.” Each explorer indexes one network. An address page for Ethereum will not show Ethersocial balances.

Explorers differ by network: Ethplorer presents Ethereum address balances, ERC20 history and charts, which shows the kind of data an explorer exposes but does not cover Ethersocial.

Proof of work and the GPU connection

Ethersocial follows the Ethereum lineage of proof of work. Miners compete to produce a valid block, and nodes accept the block only if the work checks out against the consensus rules. Ethash is designed to be memory-hard, which is why graphics cards with fast memory are the usual hardware for it, as the Ethereum documentation on proof of work describes.

The practical meaning is that the algorithm choice shapes who can take part. Memory-bound work suits widely available consumer graphics cards. Specialised chips built for other algorithms are not the target. That is a design intention, so a reader deciding whether to buy hardware should confirm the current algorithm in the project’s materials and client before spending anything.

Reading block time from timestamps

Block time is the interval between blocks, and a block explorer is the practical tool for observing it. Every block carries a timestamp. Subtracting the timestamp of the previous block from the next gives the gap for that pair. A single gap says little, because proof of work is random and gaps vary widely from block to block.

A reliable reading takes a longer run of consecutive blocks. Note the heights and timestamps at both ends of the run, then divide the elapsed time by the number of blocks between them. The longer the run, the closer the result sits to the target the difficulty rules aim for. A stated target and an observed average should agree within normal variation. If they diverge, the stated figure is probably outdated or the hash rate on the network has changed recently.

Two cautions apply. Timestamps are set by miners within limits the rules allow, so they are close to real time but not exact. Also, an observed average describes a period, and it can drift as miners join or leave. It does not promise a fixed future interval.

Where block reward figures come from

The block reward is the amount the rules allow a miner to claim for a valid block. Its authoritative sources are the project’s archived whitepaper and roadmap, the later project report and the client’s source code. Those documents are the place to read the stated reward and any scheduled change to it.

An explorer then acts as a cross-check. Open a recent block and compare the reward the chain paid to the figure in the documents. Where the two match, the figure is confirmed for that period. Where they differ, the documents may describe an earlier schedule, or the chain may have changed through an upgrade. Reward figures on aggregator sites often lag such changes, so they are weaker evidence than the project’s documents and the chain itself.

Keep the reward and the block time apart in your own planning. Reward per block and blocks per day together determine issuance, and an error in either one distorts any estimate built on them. Comparing these parameters against Ethereum’s belongs in ethersocial vs ethereum, where the shared design and the differences can be set side by side.

Consensus rules in the client software

The consensus rules are enforced by the node software. Each node independently checks every block it receives: that the proof of work is valid, that the difficulty matches what the rules require and that the transactions are well formed. A block that fails any check is rejected, however much work went into it.

This is why the source code repository is the final reference for the rules. A whitepaper states intent, while the client implements what the network actually enforces. When a document and the code disagree, the code defines which blocks are valid. Running the project’s own client, rather than software for another chain, keeps a node on the same set of rules as the rest of the network.

A short verification routine

Use these steps whenever a figure for the ethersocial algorithm, block time or reward needs confirming.

1. Read the algorithm, reward and any scheduled changes in the archived whitepaper, roadmap and project report.
2. Check the client source repository for the same parameters, since the code is what nodes enforce.
3. Open an Ethersocial block explorer and record the heights and timestamps at the start and end of a long run of blocks.
4. Divide the elapsed time by the number of blocks to get the observed average block time.
5. Open recent blocks and compare the paid reward with the documented figure.
6. Treat any mismatch as a reason to prefer the code and chain data over secondary listings.

Frequently asked questions