Does catch point saving make Algorand a centralized blockchain?

post by aybehrouz on Jan 9, 2021

Maybe I’m misunderstanding something but it seems that fast catchup essentially makes Algorand a centralized blockchain. Because state snapshots are saved on Algorand’s servers…

post by tsachi on Jan 9, 2021

Ahh…great point @aybehrouz.
But no, it’s not - and I’ll explain:
Each change to the account database ( whether locally on a non-relay, or on any of the relays ) is recorded, check-summed, etc. That allows all nodes that have the CatchpointTracking option enabled, to report the expected Catchpoint Label for any catchpoint round.
All archival servers ( which includes relays ), generates catchpoint files by default. If you would run an archival node locally, you’ll see the catchpoint files created in the genesis directory.
If you want to confirm that, you can run two nodes on your computer : configure the first one as a relay, and have the second one “point” to the first. You’ll be able to fast catchup the second node from the first node.
One thing that you’re correct about, is that currently there is no way to “import” a catchpoint file directly into a data directory. But that doesn’t make it centralized. I think that a step prior to that would be a creation of an archival of catchpoints file that would be available to the public.

post by tsachi on Jan 9, 2021

Additional to what I wrote above - the reason the catchpoints labels aren’t being generated by default on non-relays is for performance reasons : non-relays are ( in some cases ), have lower machine specs. For these, it’s important to consume the least amount of disk/cpu/memory as possible.

At this time, catchpoint files cannot be generated on non-relays. This is a limitation that might be removed in the future ( along with some code changes to support that ). So far, I have not seen much demand for that on this forum.

post by aybehrouz on Jan 11, 2021

The digest of these snapshot files is stored on Algorand’s servers:
https://algorand-catchpoints.s3.us-east-2.amazonaws.com/channel/mainnet/latest.catchpoint
Therefore when a node syncs itself using fast-catchup, it will see Algorand’s state data (including account balances) as the foundation wants. This essentially makes Algorand a centralized blockchain. If someone corrupts these snapshot files and their digest on Algorand servers, some nodes will start to have corrupted state data and likely no one will notice it. After some time when the number of corrupted nodes increases because these nodes are participating in the consensus protocol the corrupted state will dominate the valid state that the archival nodes have.

Even if you produce this digest by all nodes or even if you include it in the blockchain, still nodes that use fast catchup are vulnerable to several phishing-like attacks. The only way that you can protect nodes against phishing attacks is to save those digests on trusted https servers which essentially makes things centralized.

post by tsachi on Jan 11, 2021

But you missed a point - the node would never go to the above location to get the catchpoint label.
Algorand currently publish the latest.catchpoint to help the community.
If the service that maintain these catchpoint labels would stop working, the Algorand network would still work perfectly fine. There is no component on the system that use the fast catchup automatically.
At the moment, Algorand wait for additional individuals ( like yourself! ), to run their own node, and to create a nice user-interface with that information. Would you like to volunteer and run this service ?
( I would envision a crypto exchange letting their customers know what the latest catchpoint label is, for instance )
Last - using the fast catchup requires the user to have a trusted catchpoint label. This was said over and over. If you don’t trust the source from where you received the catchpoint label, then please don’t use it.

btw - please don’t confuse catchpoint files with catchpoint labels. A catchpoint file contain the entire accounts database. A catchpoint label is just the “round-number@hash” string.

post by fabrice on Jan 11, 2021

Note that by default the node syncs from the start and does not use fast catchup.
You need to manually get the catchpoint label and call goal node catchup to use fast catchup.
Anyone can publish those catchpoint labels and you can check multiple of them are equal before using them.

post by aybehrouz on Jan 11, 2021

As I mentioned in my post one of the problems of this approach is that because u don’t save this digest(cryptographic hash) in the block headers, a node that uses a corrupted snapshot can not detect its database is corrupted. It will work like a normal node. so if an attacker finds a way to make people use his corrupted snapshot he can produce a hidden community of corrupted nodes over time. When he made enough number of infected nodes, his corrupted state, which likely he is a billionaire in it, would dominate the real state. because his nodes are voting in the consensus.

That’s why I call this approach centralized… we have a single point of failure.

post by Rejinderi on Jan 12, 2021

is this true? I thought the latest block will contain the hash of the previous one? from there it’s possible to detect that the catchup data was altered right? what is the worse case scenario of this? even if he changed historical balances to own billion of algo will won’t be able to spend it ya?

post by aybehrouz on Jan 12, 2021

It does.
No its not possible.
But, as long as u retrieve the catch point label from a trusted source, like Algorand’s https servers, ur catch point file with a very high probability is not altered. The validity of a catch point file can be verified using catch point labels.

post by Rejinderi on Jan 12, 2021

lets say a lot of nodes are ‘corrupted’ due to this, the person who corrupted it changes his historical balances to own billions of algo, will he able to spend it? if he is able to spend it and due to the un forkable nature of algorand the whole chain loses its integrity right?

post by aybehrouz on Jan 12, 2021

if the corrupted nodes own more than a certain threshold of all participating algos the attacker would be able to spend that money.
And yes the probability of successfully doing this attack is really really low.

post by tsachi on Jan 12, 2021

If you’re going to imply a concrete vulnerability, you’ll need to explicitly specify how to get there. A core assumption in security is that you don’t want to get compromised to start with. Once your system is compromised, all bets are off.

When dealing with networked database ( i.e. blockchain ), you can’t trust anything received by the network, and you have to verify everything. However, the above assumption still holds - once you’ve verified the correctness of something, it could be assumed to hold true forever.

post by Rejinderi on Jan 13, 2021

thank you for the answers. @aybehrouz @tsachi

post by algorander on Jan 13, 2021

As a database administrator for a bank I don’t understand why the community would risk this vulnerability with integrity & fast catchup. All nodes should check all blocks from the beginning, if not sorry you cant be a node. We are too used to instant gratification in this society. But as currency is the backbone of the planet there should be no short cuts. If they have to wait 52 days then good, there are already plenty of nodes completely caught up. It separates real people vs people who are just trying to stand up a quick nodes to trick the system.

post by tsachi on Jan 13, 2021

The problem is that the above 52 days are going to get longer and longer. At some point, it would become non-practical to catchup using sequential block validation.
Using the fast catchup is like downloading a gzip file, along with a md5 checksum. If you got the checksum correct, you can verify the validity of the gzip.

post by APC on Jan 13, 2021

Great explanation, I second the need for better integrity checking on Algorand.

post by algorander on Jan 13, 2021

The difference is the genesis file can be hardcoded into the algo while catchup is always this dynamic vulnerability. Maybe if the catchup file was in github it would be ok but the safest is to hardcode it into the algorithm. I don’t really trust git anything.

post by tsachi on Jan 13, 2021

I think that moving the genesis.json into the algod binary would not make it any better from security perspective, since one would question the validity of the algod binary instead of just questioning the validity of the algod binary + genesis.json.

post by aybehrouz on Jan 14, 2021

This is not true. Genesis is a block not a state snapshot. So when u alter the genesis block you’ll have to make a whole new block chain from the start. A node with invalid genesis can not work in the same blockchain as other nodes. The same is not true about state snapshots.

post by aybehrouz on Jan 15, 2021

Integrity checking of software is not something new. For example, in windows all .exe files should have a digital signature attached to them, otherwise, the OS will display a warning when the user wants to execute them. That digital signature is a cryptographic safe hash of that file (usually sha256) signed by developer’s private key. Using those certificates requires trusting in certificate authorities like digicert, comodo, etc. In the blockchain community we are a bit paranoid and we can’t trust them. So we were discussing ways that blockchain could be itself used for integrity checking of node’s software.

The integrity of node software (i.e. protocol implementation) is an issue in all blockchain, but in Algorand is more important because all nodes are validators (i.e. miners).

post by aybehrouz on Jan 15, 2021

You are right. That’s why I changed my mind:
Still, its a good idea if developers send hashes of their software as normal transactions to the blockchain. Though, people would still need to verify that the sender account of that transaction really belongs to official developers.

post by aybehrouz on Jan 15, 2021

The same thing applies for catch-point files. Instead of having their label on amazon servers, foundation could send them on blockchain as transactions. This way we won’t need to trust amazon servers