How Ethersocial Worked

Anyone asking how does ethersocial work is really asking what happens after a wallet sends coins. In short, Ethersocial followed Ethereum’s account model: signed transactions were gathered into blocks, mined, added to the chain and re-checked by nodes.

This guide covers the mechanics only. The wider story of the ethersocial coin and its community has its own page, and each misconception below is resolved with the technical picture.

Accounts and state: what a wallet actually holds

A common assumption is that a wallet stores coins, like a purse. On an Ethereum-derived chain such as Ethersocial, the coins are not stored in the wallet at all. The wallet holds a private key that controls an account recorded on the chain.

According to Coding Bootcamps’ explanation of Ethereum accounts, Ethereum manages accounts and state instead of the UTXO model used by Bitcoin. Each account has a 20-byte cryptographic address, plus four fields: a nonce, a balance, contract code and storage. The collection of all accounts is the world state, which is the global state of the network and is updated after each transaction executes.

This matters when judging any Ethereum-derived coin. The balance you see is a field in an account, and the nonce, the account’s transaction counter, ties each transaction to a sequence. Nothing about the model depends on the coin’s branding.

Two kinds of account

Accounts split into externally owned accounts and contract accounts. The table sets out how they differ in practice.

These account details come from Coding Bootcamps, which describes the account types as they work on Ethereum.

Anyone using a wallet for Ethersocial is operating an externally owned account. Contract accounts matter only if the coin’s chain hosts deployed contracts, and they cannot be spent from by a person directly.

Sending and confirming a transaction

A second misunderstanding is that a transaction is instant and final the moment you press send. A signed transaction is only a request until it is included in a block.

The owner uses a private key to digitally sign every transaction, as Coding Bootcamps notes. The signature lets the network verify that the sender controls the account without the key ever being revealed. Keeping the key secret is therefore the whole of wallet security. Anyone who obtains it can sign for the account.

From wallet to block

Signed transactions reach the network and wait to be collated into a block. That covers ether moving from one account to another and smart contract code being executed. Once a block containing the transaction is mined and added to the blockchain, the transfer has been recorded in the chain’s history and the world state is updated.

• Signing: the wallet signs with the private key, which proves control of the sending account.
• Collation: the transaction is grouped with others into a candidate block.
• Inclusion: the block is mined and added to the blockchain, which is what makes the transfer part of the record.

For a recipient, the sensible habit is to treat a payment as settled only once it appears in a block, not when it is merely broadcast. A transaction that has not yet been included is still pending.

Producing and validating blocks

Blocks are not written by a company or a central server. The new block is mined by the blockchain network and added to the blockchain, according to Coding Bootcamps. Mining is the work that earns the right to extend the chain, and it is why mining hardware features so heavily in discussion of coins like this.

Mining and validation are different jobs

Producing a block and checking one are separate steps. A miner assembles and mines a block. Other participants then verify it. For contract transactions the check is concrete: all participating nodes execute the contract code again as part of the block verification process. A block whose results do not match what the nodes compute does not belong in their copy of the chain.

The practical consequence is that nobody has to trust the miner. Each node can reach the same world state independently by replaying the block’s transactions.

Hardware and what it implies

Graphics cards are the usual hardware for this kind of work, and a rig is a stack of them sharing power and cooling. Owning such hardware is not needed to use the coin. Sending and receiving requires only a wallet and a network connection.

Client software also matters. The Geth implementation, for example, uses Google LevelDB as the underlying database for the global state, per Coding Bootcamps. A node operator is therefore running software that stores and updates the account state, not merely relaying messages.

Smart contracts and the Ethereum Virtual Machine

Could smart contracts run on it? Yes, if the chain behaves as an Ethereum-derived network, and that is the main reason to describe it that way. A contract account holds code, and the Ethereum Virtual Machine activates and executes that code whenever the account receives a message.

The difference this makes is large. Coding Bootcamps observes that without contract accounts Ethereum would be limited to the mere transfer of value between accounts, as with Bitcoin. Contracts are what turn a payment network into a programmable one, and the Ethereum Virtual Machine is the part that makes the same code produce the same result on every node.

A contract’s own address is not chosen freely. It is calculated with the Keccak-256 hash function from the creator’s address and the creator’s nonce. A developer can therefore know where a contract will live from the deploying account’s state.

Developers deploying to such a chain should assume the Ethereum tooling and contract model carry over. Whether a particular application exists on Ethersocial is a separate question, to be checked on the chain itself rather than assumed from compatibility alone.

How Ethersocial differed from Ethereum itself

The core machinery was shared, so the differences lie elsewhere. Accounts, signed transactions, mined blocks and EVM-based contracts are Ethereum design. Ethersocial was a separate chain built on that design, with its own network, its own coin and its own community aims.

The positioning belongs to the project’s own documents. The ethersocial whitepaper sets out the claims the project made, and those claims are a different thing from the protocol behaviour described above. Likewise, the ethersocial network foundation page covers the organisation around the coin rather than how blocks are made.

Keeping ideas apart from infrastructure

Social visions are easy to mistake for features. Commentary from Bankless on the decentralized society idea makes the point well: it describes the concept as a field of study rather than something that can be examined in the wild today, while noting that Ethereum and NFTs already provide the basic infrastructure. The same reasoning applies here. Community goals describe intent. Accounts, blocks and contracts describe what the chain does.

• Shared with Ethereum: the account and state model, signed transactions, mined blocks and EVM contract execution.
• Specific to the project: the coin, its network and its community purpose, covered in the whitepaper and foundation pages.
• Not a technical feature: any social aim stated in project documents, which should be judged as a claim rather than as protocol behaviour.

Frequently asked questions