Anatomy of Bitcoin's blockchain

Archives Discussion
1

I wanted to share with you my analysis of Bitcoin’s blockchain, since proof-of-work is regularly put on the table for many P2P projects (Altcoins, Ethereum, Twister, …) but still under the same form.

Also, I will give you a short presentation of what uCoin could do instead.

So, what is Bitcoin’s blockchain?

Basically, this blockchain fits 2 major requirements: synchronization, security. Let’s detail those points and see the consequences of such system and how we could go differently.

1. Synchronization

The very first requirement is sync: the fact the network orchestrates changes (a) and about a common data structure (b).

Indeed for (a), the network is constantly waiting for a valid block, which may come from any peer (more or less randomly). Since blocks are long to compute, the probability to have 2 valid blocks at the same time is rather low and allows to consider the reception of a block as in a FIFO queue. With proof-of-work, we thus have:

  • Avoided spam (blocks are easily checked for validity)
  • Common timpestamp (a chain of blocks)
  • Random speaker on each turn

And of course (b), as the blockchain is made to agree on a common “thing” while in a decentralized structure. Here in Bitcoin, common agreement is about transactions & money issuance (which are mixed up in Bitcoin).

2. Security

The second requirement is security. Of what? To protect from whom? The security of the blockchain building against people in a an unidentified network, since participant are not known (we don’t know who or even what we deal with).

So in such a network, we use CPU resource as a discriminant to represent people. But of course this approach is very biaised, since richers may easily own more CPUs than others, or simply people may group together to get more CPU power. So in the end, we never know who is what and who does what.

We may think Bitcoin is secured thanks to CPU power repartition, which would be almost equally distributed between users (humans). But this is a believing only. Not an observable fact.

Consequences

Consequences of such an architecture is:

CPU race

Here we are talking about miners, i.e. people joining the network and participating to blockchain building to get newly issued coins. Indeed, the more CPU you have the more new coins you get. But as global CPU increase, proof-of-work becomes harder. This lead to a huge amount of CPU power (and electricity!) wasted just because we are in an unidentified network, as CPU power play the role of identity.

No Universal Dividend

A direct consequence is that no Universal Dividend may exist, since people are not clearly identified.

What other solutions?

Well, the basic idea is to identify actors. Incredibly simple, I know. But from this change of referential, here is a huge consequence: we no more need CPUs as an identifier, thus no more CPU power race.

But be cautious, we won’t throw the baby out with the bathwater: what we’ve just done is to throw away security problem, no the synchronization one. Here, I think proof-of-work has huge advantages, allowing easy sync in a decentralized network.

So yes, proof-of-work is still here. But no more with an escalation of required CPU power. But then, what if a precise peer has really more power than others? Would he have the privilege to build then blockchain alone?

Well, here the area of solution is probably wide: personally, I think a simple rule like:

Each time a member adds a block, his next block will be harder by one magniture order for the next 10 blocks.

With such a rule, a member will be handicaped for a bunch of next blocks, allowing other members to succeed before him. I know, 10 is both tremendous and ridiculous depending on the community size. But you get the idea.

So, have any opinion about all this? Let’s talk!

3 Likes
2

Hi.

By “identifying actors”, if you mean that everyone who participates in the money issuing is trusted by all the network and cannot act badly, then the consensus problem you are facing is different from the problem proof-of-work blockchains solve. I’m not an expert, but I think Raft is an example of such a distributed consensus algorithm when everybody trust each other. There may be other algorithms.

If you have a network and you are ok to identify only some actors of the network, not all of them, then you may apply the consensus algorithm of Ripple : it is a distributed consensus without proof-of-work. Each node has to select a set of “miners”. These miners don’t need to be fully trusted, only not to collude with each other.

3

Hi Hugo, thanks for your reply.

“identify actors” here does not mean that we trust them (i.e. their acts), but we trust their identity. This point is very important, and does not lead to the same results than trusting peers themselves (you mentioned Raft as an example, I did not know its existence, will check it out).

Bitcoin really try to solve an identification problem too, even if it is not obvious since several problems are solved by Bitcoin’s PoW.

I do not know very well Ripple. But from what I’ve read we are in a similar situation of trust of people acts, not identities. Furthermore those trusted people are a (pre?)defined group, introducing centralization, and also introducing asymmetry in time (what will happen in 80 years? will the trusted people be the same in Ripple?).

The whole point of uCoin is to first define identities and give them the same power of action according to predefined rules, and use PoW mechanism to synchronize their actions. It seems different from Raft & Ripple.

4

Ok, so there are known identities, but we cannot trust their acts. If I am correct, you want to avoid CPU races. So that every node in the network has the same opportunity to “speak”. So each one could speak with a probablyy of 1/N ?
Why do you need proof-of-work for that ?

To complete about the Ripple consensus algorithm : you have to trust some identities (validators). Each one can trust a different set of validators and this set can be changed at any time. You don’t have to fully trust their acts, only that they won’t group to act badly. For example, you know the identity of Itchy and Scratchy. You cannot really trust them, but you know they won’t work together to fool you.

5

It’s the idea, however 1/N is a protocol parameter and can be any other value. I would rather bet on % of N, like 5% for example, since we do not need all the members to participate in a circular way. It might be a constant too. More precisely, what we want is to put a temporary handicap to those who succeeded in writing a block to allow others to do it.

For synchronization.

About Ripple, thanks for the details. Indeed, it is a different consensus mechanism. However, I perceive here that the system will tend to centralization since to commonly agree on the same data, participants are suggested to agree on the same people, leading to concentrate power into few hands. Isn’t it?

6

Ok, then your proposal seems to work, but I still have the feeling that proof of work is not the best tool here, but I may be wrong, that is just a feeling :slight_smile: I mean, why ask participants to prove they have spent CPU power if you know the list of participants that are allowed to commit a block ? If someone spams the network, you can warn him or ban him, right ?

I still need to read your code / docs to be sure I understand correctly all your system.

Participants are suggested to choose a subset of a list of validators. If the list of validators is long enough, it will tend to be distributed. But it takes time to have enough validators that are publicly known. So, yes at the launch, the network is concentrated. After some time, it should be decentralized.

7

I do not need a proof of CPU power usage, but rather avoiding spamming for both a single peer & the whole network. For example, that’s true, we could avoid spamming of a single peer using some arbitrary protocol rules. But how to avoid spamming for the whole community? (i.e. avoiding 100 members to write the next block approx. at the same time)

PoW actually brings 2 features:

  • Scarcity of a resource (CPU power) avoiding single entity spamming
  • Randomness avoiding multiple entities spamming

Those 2 features are what I call “synchronization”. I do know yet any other way to avoid multiple entities spamming in an untrusted P2P environment.

I still have many outstanding questions about this… like:

  • How are chosen suggested validators?
  • Does anyone can be a validator? Is it an individual?
  • What happens if validators do not agree?
  • How much validators can exist in a given Ripple network?

I think that, if there was an issue here to be found, it would be about centralization: since power is given to few hands, those hands are subject to failure (corruption of the people or software). Whereas in a P2P network, the whole network can be destroyed only by taking down all its peers.

Well, I guess you already know that :slight_smile:

8

You’re right, you need “randomness”, or rather : you need each participant to share the same global state, i.e. the same list of state changes, in the same order. Who speaks first and after whom is not important. PoW gives you this, but at the price of a CPU race.
I am still not sure RAFT or equivalent (are there any other ?) are to be buried here.
Consensus algorithms are hard to prove. So, that would seem to me a bit better to use an existing algorithm that is proved to work, rather than trying to modify another one.

Clients may choose any validators they want. Validators tend to publicly claim they are up and running.

It is free to anyone. For the current implementation of Ripple, something able to run the Ripple server

The majority wins. There can be temporary forks too, like with bitcoin

There is no particular limit.

I really don’t think it is centralized :slight_smile: At launch, it could be, be as soon as the small group of launchers are doing something bad, clients can switch to other validators without effort.

9

uCoin’s PoW is not like Bitcoin, there is no CPU race in it:

  • Bitcoin = globalized PoW (CPU race, exacerbated by mining mechanism)
  • uCoin = individualized PoW (huge handicap after writing a block, no particular interest in CPU race, peers may just “wait” for their turn)

I prefer to give a chance to uCoin’s algorithm. :slight_smile:

Now, about Ripple:

So, what prevents a group to create many servers and take the control?

Are servers identified & authentified? Through which mechanism?

10

I suggest you to not read the code yet, since it is a mess for now :slight_smile: (I am migrating code to the PoW system I am describing here).

And if you had one document to read, I would say Protocol first. You may also read Theoretical part on uCoin website and FAQ, but these documents are to be updated to match the protocol.

11

Of course :slight_smile:

Reputation ? Lots of validators can exist, but every client has to choose its own list of validators (called Unique Node List). And everyone is really encouraged to choose validators that are the most “distant” from each other: geographically, ideologically, linguistically, etc. There is thus a low probability to choose validators from the same group of people. Validators are alos encouraged to be as transparent as possible about their identity.

I am not sure to understand this question. Each server publish has its public key …

12

Ok, then this looks like what I had previously for uCoin for transactions’ storage. I wanted this storage to be completely decentralized, and imagined a similar system were reputation was the key for agreeing on a shared state of transactions.

But in my mind this would lead to focus decisional power into few hands, the “reputed” nodes. I may be wrong about it, but I havn’t succeeded in escaping this intuition yet and decided to switch to another model.

I keep the idea in mind, then :slight_smile:

OK, so a server’s identity is linked to its public key I presume. However, is there a “real” identity linked to the public key? (like an individual name, company name, …). And if so, how can we be sure this identity to be really owned by the correct owner?

A major problem that may come up if identities cannot be trusted is: multiple accounts owned by a single individual or company. Again, this leads to centralization issues.

I promise I am not “centralization” monomaniac :blush: but ignoring this cause won’t avoid its effects. And my guess is that over long term, choosing few entities to decided will focus power on them.

13

How do you know who is behind the website server of a company / organization / individual ? If this company / organization / infidivual is not transparant enough, then noone would want to trust them as validators …

Yes, this is the whole point of validators being transparent with their identities: give trust.

You’re right to be attentive about the centralization issue. It’s a hard problem. You may be right if the number of entities to trust is too small compared to the size of the network.

14

Le Pôle TES, pôle de compétitivité consacré aux transactions
électroniques sécurisées, organise une conférence autour de Bitcoin et
de la Blockchain mercredi 25 mars 2015.
https://youtu.be/jbN8ucwWR2A

15

Are you saying that uCoin uses a blockchain just like Bitcoin does?

I understand it won’t use a PoW race, because it has become clear to, I hope everyone, that the Calvinistic approach “The only way to earn money, is that you MUST work hard. (or if you sufficiently have broken down that argument, work smart (whatever that means))” isn’t working when all the work is done by computers leading to a single centralized computer network mining all the bitcoins.
Well it still does work, it just lost it’s decentralization, wealth distribution and security.

Here’s the sad example of that:

But my question is, am I going to have to download 1+ TB of data in 2018?
I don’t like that prospect, but I can understand that as there’s only one cryptocoin I know of that wants to break that chain.

16

If you’ve read the first post of this subject, you understand that yes, uCoin uses a Blockchain. Actually, a Blockchain is just the concept of coherent and sequential data flow which, once fully processed, gives you the whole database. That’s it: blockchain is just a database.

The fact Bitcoin creates money through computation of new blocks does not mean every blockchain based software also creates money through this mechanism, nor is a currency software.

Again, in uCoin, currency is created through Universal Dividend. Their is no more to say about this point.

No, you won’t need to download all the historical data. You just need a snapshot of current data. For now, you need to download the full history. But the next development steps will be to avoid this, since it is:

  • costly
  • not useful if you don’t want to anayze historical data

Which is?

17

Okay, I understand it then. I thought blockchain specifically stood for “a database that contains all historical data in order to preserve a secure decentralized digital currency system”, which I understand is a necessity for Bitcoin and all other altcoins bar uCoin and MaidSafecoin in order to run properly?

I imagined a blockchain to be a chain of transaction data. and “the ones that want to break that chain of transaction data” being uCoin and MaidSafeCoin, so I was surprised to see “blockchain” and “uCoin” in the same sentence.

To me this means that only uCoin and MaidSafeCoin are the only two coins worth following or investing time&money in, as the others have poor scalability, with the exception of BitShares’ digital fiat currencies.

1 Like