Some Questions About Algorand

Hello,

I have been digging in the technical merits of Algorand. The whitepapers and the website gave me plenty of information but there are still some tidbits of information that I’m hoping I can get answers on. Some of my questions might be silly but please bear with me. Please see the following for my questions:

1. I know they say that Algorand gets confirmed in like 20 seconds or so. This is one confirmation. Is there only one confirmation in general? How many confirmations would be considered secure for Algorand?

2. I am curious about Algorands’ transactions per second (TPS). It’s well known that Algorand gets confirmed in less than a minute but is there a number for the TPS somewhere?

3. Algorand requires that 2/3 of network participants are honest. What is it exactly about Algorand that pushes this number higher than the usual ½ honesty threshold of many Proof-of-Stake cryptos?

4. Has Algorand already implemented sharding or is it just future plans?

5. What were the token date launch, testnet launch, and the mainnet launch dates?

6. Let’s suppose the winner of the random selection decides to make a malicious transaction. Doesn’t he have all the power to make a malicious transaction?

7. Can someone ELI5 how the stamping certificate works for Algorand, technically?

8. Why are staking rewards external to Algorand? Am I right to understand that all network rewards aren’t directly built in the Algorand blockchain but are included externally?

9. Can anyone tell me a bit about how the fee system works? Is there a minimum fee? Can anyone set a fee?

10. Are Algorand’s performance numbers based on number of users or nodes?

Thanks for your help!

Hi @tylerswob,

I’m not sure that I have the answers to all your questions, but I could try to take few off this massive list :

1. A transaction is typically confirmed within a block. A block is roughly generated every 4.5 seconds. Once a transaction is confirmed to be included in a block, the transaction is final.
2. Previous conducted tests shown a TPS rate of 1000. I don’t have a precise test or reference for you at this time. ( sorry ).
3. I’ll have to pass on this one. You might want to take a look on the papers again for further mathematical clarification.
4. The need for sharding came from other blockchains that where inherently less efficient. There, the sharding concept was making a notable overall performance gains. The Algorand implementation is already extremely efficient ( please don’t trust me; test it yourself ! ), and therefore sharding per se isn’t required.
5. The Algorand mainnet network was launched in June 19, 2019.
6. No. As per the paper, there are multiple block proposers, and multiple block verifiers. A committee is chosen for each of these steps, which makes it much harder to make a malicious transaction.
7. sorry, I don’t know the answer for that.
8. All the rewards are controlled externally so that the Algorand foundation could throttle them according to the current token economics. However, there are no secrets at Algorand. You should know exactly how many rewards you’ll be received via the various rewarding plans.
9. Each transaction has a minimum fee. The fee goes into a special account, that ( currently ) is untouchable. In the future, the funds in the account might go back as a reward or used to cover the network operational costs. The minimum fee is hard coded. Transactions competes between themselves for entering ahead of others in the transaction pool.
10. Could you provide some reference to the above graph ? where did it came from ?
    ( I’m not sure what the answer to your question )

Hope the above helped.

Tsachi

more on rewards:

4: To add to what Tsachi said: Once the network scales enough we may implement sharding; one possible picture of what that might look like is described in the Vault paper.

6: To add to what Tsachi said: If a block proposer sends out an invalid block, then no honest user will cert-vote that block, so it won’t get confirmed, and everyone will move onto the next period where someone else will propose a different block. The papers don’t explicitly mention it, but before cert-voting we don’t just check whether we have a block but also whether that block is valid.

7: If you’re talking about stamping certificates from the Vault paper, those aren’t implemented yet (in fact, most of Vault is not implemented
yet), but the idea is as follows:

For Vault, the goal is to catch new users up to the current state of the network as efficiently as possible. This involves sending them block headers and certificates. Stamping certificates are a way to make smaller certificates, thus making catchup faster.
We can get smaller certificates by tweaking some parameters for committee selection, but the catch is that with these different parameters every so often it might be impossible to make a certificate for a block. So we don’t want to mess with the parameters used for cert-votes, because
then we might sometimes fail to agree on a block. Instead, we’ll introduce a separate committee – the stamping committee – that uses the new
parameters. Once a block is confirmed the normal way (and everyone moves onto trying to agree on the next block), this committee will try to make a stamping certificate for the block that just got confirmed. If they succeed, we now have a smaller “stamping certificate” that can be used instead of the normal certificate when catching people up. If they fail, we can still fall back to the larger regular certificate (or better yet, we can use a different optimization that I can explain if you’re interested).
TL;DR: A separate committee tries to make small “stamping certificates” on blocks as soon as they get confirmed, and if they succeed, then these smaller stamping certificates can be used instead of the usual certificates when catching new users up, making catchup faster.

Thank you so much for sharing your insight!

Adam, one more question if you don’t mind.

How does Algorand’s defense with the Long-Range Attack and Nothing-At-Stake attack vectors add up compared to other POS systems? I read that Algorand doesn’t really fork which is contradictory to the Nothing-At-Stake attack vector so I’m curious about that. Similarly, if it so happens that a set of validators have at least 33% of coins is there a risk of a Long-Range Attack? Please let me know if I’m completely off the base.

Thanks!