FAQ

[aybehrouz]

In very simple terms, eth is a platform for building dapps, btc is a digital store of value...
I just described all of those things in a way most people count understand as long as they learn or already know one or two key terms, Can you please do that for Argennon?

In terms of functionality, Argennon is exactly like Ethereum.
Also note that ETH could be considered as a store of value, like bitcoin.

What makes Argennon different?

https://www.argennon.com/features.html

Why do we need a cloud based blockchain? Isn't it actually slower?

Assume that user A sends 1 ETH to user B. This is a transaction. For validity of this transaction, user A needs to have at least 1 ETH, otherwise that transaction must be rejected. Who is actually checking that? We all say that crypto is a decentralized world, but how many of Ethereum users really check the validity of this transaction?

For validating a transaction, you need to run a full node. Do you know anyone who is running a full node? I don't. We all prefer to use a phone wallet and leave the hassle of running a node to others. OK, Lets say that you are running a full node. But what happens when your full node detects an invalid transaction? Nothing! Your node has no role in Ethereum protocol. It can reject that transaction inside its little internal world but it can not do anything more than that. Your node is not doing anything in the process of block validation.

You may think that miners are verifying that transaction. But that is not true either. Most miners are just wasting energy calculating useless hashes. They do not check any transaction because they are part of a mining pool, and the pool is the only one who checks the validity of transactions.

So the fate of our transaction is in the hands of only 6-7 mining pools. They decide everything while no one really knows who they are and what they are doing.

In my opinion, decentralization is a lie as long as in our example an ordinary user is not able to verify user A really owns that 1 ETH.

For doing that, a normal user needs to keep ETH balances of all users. Now let's do some calculations. Assume ETH has become really popular and almost every person in the world owns some ETH. (That is not unrealistic for a worldwide currency) In that case assuming 10 billion accounts with none-zero balance is not unrealistic. ETH balances are stored using 256 bit numbers. So for storing ONLY balances we need 320GB of storage. (In practice we need to store keys besides balances, so the correct number is 640GB)
Also note that in a real world application balances are not the only data we need to store.

This issue exists in any blockchain. While we talk about decentralization a lot, In reality transaction validation can only be done by a few people who are ready to devote a large amount of resources for preforming costly transaction validation.

Why is Bitcoin centralized?

That's really obvious. Everything is decided by like 4-5 major mining pools. If they decide they can revert any transaction, which means your money will go out of your wallet or they can reject any transaction which means they can freeze your bitcoins.
To be honest I'm not even sure that they have not forked the bitcoin chain yet, because forks can happen as a part of the bitcoin protocol and no one may notice! lol

Is it even possible? true, flawless, decentralization?

But, is that a good thing? flawless, pure decentralization? When I was writing the Argennon paper I realized that the answer is probably negative.

Assume that you have a system consisting of 1000 users. The system is truly decentralized and is controlled by those users. What happens if a malware attacks the system? What happens if the malware infects more than 70% of users' computers? In that case, the malware would be able to control the system.

The thing is, those 1000 users are actually clones of a single user in that malware's point of view. Same OS, same hardware... A sophisticated malware, which uses zero day exploits, is arguably able to infect 1000 users as easy as 10 users.

That's not the case for centralized systems. Attacking Google is not like attacking Amazon. Because those are systems that are engineered to defend against cyber attacks. They are not simple clones of each other, and each one likely uses a different approach/technology for security.

Even if we assume that centralized systems are similar like ordinary systems, still in my opinion, performing a malware attack against a secure centralized system is much harder than infecting 70% of all normal personal computers of the world.

Decentralization does lead to high security but in a social perspective. The boss of that centralized service may decide to steal your money and do bad things but that's not the case for the decentralized system.

But isn’t there a way you could have high decentralization meets high security?

I think the Argennon solution is notable in this regard. In Argennon we have a hybrid system. (usually) Five centralized systems are democratically elected by users through the governance system. Those delegates will be responsible for proposing blocks (i.e minting new blocks) then those blocks will be verified by a truly decentralized system, which requires the participation of almost all Argennon users. Consequently, for attacking Argennon you need to attack both a centralized and a decentralized system.

In my opinion, this system is like a true democracy. You elect some delegates then you carefully watch and verify everything they do. If they do something wrong they will be replaced.

Some people say that mining pools in bitcoin are some kind of delegates, since they are chosen by small miners who are using those pools. I do not agree because there is no transparent process for electing them and users choose them based on profits they give. Even if we assume that they are elected democratically still they're somehow doing whatever they want. Even full nodes can not exactly verify what they do.

On the other hand, Argennon is a cloud based blockchain. Users are constantly monitoring what delegates do (this is done programmatically) and users issue block certificates. Protocol requires those certificates. If users stop giving those certificates the whole blockchain will stop.

In Argennon absence of a single delegate will halt the blockchain. I think it is called a single point of failure in distributed systems....

The idea here is to choose security over availability. We could've said that 3 votes of 5 was enough. That way even when two of delegates are down, the system will keep working. However I personally believe, that would be a wrong design. What we should be worried about here is security, not availability.

Just a few days ago an exploit was found in log4j. That exploit allowed an attacker to essentially execute any remote code on a victim's machine. Almost all java programs use log4j. What could happen if an exploit like that is used to attack our system? I'd say, with high probability at least 3 delegates would be hacked, but at the same time with a good probability one of them may stay unaffected. (For example since it doesn't use java) In the current design that sole delegate can stop the attack totally. The system may go down for an hour but the consistency of the system is preserved.

One important thing that we should not forget is that the committee of delegates can be engineered for reliability. "What if one of them goes down due to a problem like the one Facebook had?" The point here is that as long as a delegate keeps up a simple service for issuing signatures, even if it can not verity transactions any more, the system interruption can be avoided.

In other words, delegates could have backup systems that only issue signatures without validating any transaction. That simple service can be hosted anywhere because it is not as complex as the full system. When the main system goes down If managers believe that there is no security threat they could active the simple signature issuer service. This system essentially delegates their right to other delegates because it doesn't verify transactions.

on floating point support.... ain't floating points a really dangerous mathematical tool in accounting?

In Argennon we have signed integer and signed floating point arithmetic, and there is no support for unsigned arithmetic.

You may have heard that you should not use floats for monetary calculations. The reason behind this advice is that some inexperienced programmers think because some currencies have a decimal point in their representation they should always use float for representing them. For example, they think because there is a decimal point in $1.23 they need to store it in a float. As you know 1.23 does not have a finite binary expansion. Converting 1.23 to a floating point number will always introduce a small error, it may be converted to something like 1.22999954233 or 1.23000054156 (note that this happens only for numbers with an infinite binary expansion) This small error can easily become problematic for our inexperienced programmer.

The fact is, as long as you are doing only addition and subtraction, you don't need float arithmetic. That decimal point in USD is irrelevant since the number of digits after the decimal point is always fixed. In everyday monetary calculations like simple buying and selling of non-fungible goods usually we only use addition and subtraction. That's why our programmer shouldn't use floats.

However things will change as soon as you need to divide two numbers. Again the decimal point is irrelevant here, this also applies to integers like 2, 5, 10. Doing arithmetic that includes division with integers is a dangerous practice. Integer arithmetic has a fixed absolute error. That's why 1/3 completely disappears in integer arithmetic. Any time you need divisions (or any function including division like log, sqrt , ... you should definitely use floats because floats have a fixed fractional error and at the same time, they are very efficient.
It turns out that using equations including divisions is quite popular in smart contracts. that's why we have floats in Argennon.

Of course when you are doing any type of arithmetic you should always think about error and how it is accumulated and rounded. Removing floating point numbers will not remove arithmetic error magically. It actually makes handling it much more difficult. That's why in a system which does not have floats they had to use 18 decimals for representing BUSD when in the real domain it doesn't need more than 2 or 3 decimals.