Please someone answer my questions :(

Hey there,

My bachelor thesis will be related to Algorand and I need to develop a banking application, for people who are interested here is my topic description:

Some questions came up while doing my research and I’d be happy if someone answered all of them. Thanks in advance!

1Q: In this video Algorand Blockchain Core Protocol Overview - YouTube at the 3:30 mark it is said that if a node receives multiple block proposals, the node will compare the vrf proof of each and keep the one with the lowest proof/hash. What does this mean (lowest hash/proof) and what does it represent? Does this signify who won the “lottery” first?

2Q: Here The Algorand Blockchain Explained regarding the recovery mode, where a new creator to build a block must be selected if the previous had fraudulent transactions in his block, does the process start from the beginning or do you take just the second node with the second “lowest vrf proof” to propose?

3Q: Is TEAL still not Turing-complete or this was in the past?

4Q: If ABI was so important for the SCs (smart contract) to know how to properly communicate with each other, then how did things function before the ABI? Did you have to notify others every time you create a SC about its existence, or everyone who wants to communicate with your SC had to see first its internal structure?

5Q: ARCs: Algorand Requests for Comments, with Ethereum it is called ERC. What is the meaning of the name? It is not self-explanatory in my opinion, that’s why I am curious… This just represents standards, right? For example ARC4 is the standard that explains the ABI

6Q: What are dynamic and short-lived smart contracts on Algorand? Can you give me some examples? What is a scalable and extendable smart contract?

7Q: Can we use the “note” field in Inner-transactions?

8Q: A clear state call allows us to remove any local storage connected with the smart contract, why do we need such functionality? I mean if the local state of this account is important for the smart contract and suddenly this account clears its state and relationship with the SC, won’t that cause some problems? If close-out is saying that accounts can’t remove the local state, there is a reason, and doing the opposite should have some consequences, right?

9Q: I know we have a maximum of 16 K-V pairs per opted-in account? If I write before deployment:
local byteslices = 7
local integers = 8
Does this mean I have permission to write up to 7 byteslices and 8 integers per opt-in account?
How many k-v pairs can an account store? If it is opted-in to 200 SCs for example, then the max is 3200 local k-v pairs, but does this go to infinity, are there any limits? Also does the same apply to the smart contract? Can it have an infinite number of accounts opted-in?

10Q: Can a stand-alone account see its local states connected with the different SC it has opted-in to?

11Q: Global storage is stored in the creator account, so that account is responsible for the global storage minimum balance? When an account opt-in, it is responsible for the minimum balance of local storage? So if the creator is responsible for the min balance of the smart contract that he creates, what happens if the account runs out of funds? Will the SC then be still active, or to activate the SC, the min balance should be restored?

12Q: If the smart contract is deleted, are the global state and local state associated with the SC also deleted? How exactly do we delete something from the blockchain, weren’t all records immutable? Why is an “app delete” function possible at all then?

13Q: Smart contract details - Algorand Developer Portal I couldn’t understand exactly how the whole reading of the scratch space functions. We have a group of transactions that we send from one contract to another and also we write something in the scratch space, then the contract we are calling can read the scratch space? Is this the only way that Algorand allows smart contracts to send data to each other, is this the equivalent to data payload in Ethereum? How about the note field in a transaction? Can it be used to control how the called smart contract proceeds with its logic?

14Q: Can it be said that the account array and application array are never empty because on Int(0) we have the sender of the transaction and the current application id respectively?

15Q: Can we mimic/imitate Inheritance behavior in Algorand? I know that traditional inheritance is not possible, but how can we replace it?

16Q: Are there any examples of dApps that implement the proxy pattern and self upgradable smart contracts that I can look into, I will need this for my dApp, can you please send me some links?

I know that the questions are a lot, but I will be grateful to anyone that took the time to respond to all of them! Please send me links to any documentation or demos that can help answer my questions. It is not needed to even explain it to me in detail, just send me a link where there is information! Thanks in advance again!

Hi Vasil,

I can weigh in for some of these:

1Q: from https://www.algorand.com/Algorand%20Protocol.pdf
VERIFIABLE RANDOM FUNCTION
Recently we released the source code for our implementation of a Verifiable Random Function (VRF).
The VRF takes a secret key and a value and produces a pseudorandom output, with a proof that anyone can useto verify the result. The VRF functions similar to a lottery and is used to choose leaders to propose a block and committee members to vote on a block.

3Q: look at the first result of googling your question Is TEAL still not Turing-complete or this was in the past? - Google Search

5Q: its just how the protocol is called. It follows the Ethereum standard. If you google your question you will have the answer as firts result:
https://www.google.com/search?q=erc+ethereum+why+is+it+called+comment&rlz=1C5CHFA_enAU930AU930&sxsrf=ALiCzsZQDNm-EdEsXZKqz6UDBEPNLTKCqg%3A1653718685146&ei=nb6RYs3HCNmMseMP6OqZwAk&ved=0ahUKEwiNiqWWxoH4AhVZRmwGHWh1BpgQ4dUDCA4&uact=5&oq=erc+ethereum+why+is+it+called+comment&gs_lcp=Cgdnd3Mtd2l6EAMyBwghEAoQoAEyBwghEAoQoAEyBwghEAoQoAEyBwghEAoQoAEyBAghEBUyCAghEB4QFhAdOgcIABBHELADOgcIABCwAxBDOgUIABCABDoGCAAQHhAWOgUIIRCgAUoECEEYAEoECEYYAFCLAVi5G2C7HGgBcAF4AYABlgKIAaIjkgEGMC4xOS41mAEAoAEByAEKwAEB&sclient=gws-wiz

Q8: again, already asked Clear state reason

Q9: already answered Question about local storage limits for smart contracts - #2 by ryanRfox

11Q: accounts are prevented from performing a transaction if they would go below the minimum balance

12Q: see what goal app delete does from the docs goal app delete - Algorand Developer Portal
I am just assuming, but I would assuming the app can be deleted, but the transactions associated with the app remain, granting the immutability of what happened. You can set your app the reject delete transactions to prevent it from being deleted

def handle_deleteapp():
    return Reject()

15Q: I am not sure but the way you want to look at any algorand sdk in any language, as instance pyteal, is that they generate TEAL code that gets executed. As such they are limited by the constraints of TEAL.
Assuming your thesis will take a while you probably want to learn some teal, and then see how your code compiles it to then see how it can be optimised

16Q: unfortunately I couldn’t find any

Hope this helps, since many of these questions are easily answered by google, I would recommend doing your research before posting, this will help people not getting put off by a very long question.

2 Likes

Thank you very much :))

Yes, you would need to know in details how each smart contract you needed to communicate with worked and write specific code. ABI significantly simplify this.

Inner transactions allow to use all the fields now.

You can use the indexer or the algod API to see all the local states of any account.
There isn’t really a notion of “standalone” account on Algorand. All accounts are handled the same way. The only difference between accounts is how transactions are approved:

  • basic signature accounts require an ED25519 signature (as a very rough first approximation, it’s like an externally-owned account on Ethereum)
  • multisig accounts require t out of n signatures
  • smart signature contract accounts (not to be confused with application accounts or smart contracts) use a smart signature for approval (it’s a bit like Bitcoin script, though much more powerful because of specificities of Algorand)
  • application accounts are controlled by a smart contract

Global state would be deleted. Local state may be manually deleted.

Deleted means that it is not in the state / account table of the blockchain.
However, if you look at the blocks themselves, you would always be able to get the full history and find out what was the local states and global states of any application / account at any point in time.

To understand better the difference between state and full blockchain, see my slides:

The full blockchain is around 800GB today (size of an archival node), while the state is less than 20GB today (size of a non-archival node).

Use of scratch pad should be limited to very specific use cases.
The proper way to communicate between smart contract is now via the Log according to the ABI.

The note field can be used to store a little bit of information on the blockchain. For top-level transactions, it needs to be specified at the submission time and cannot be modified by the application. It is mostly used for applications that do not use smart contracts (like the current governance) or for storing asset metadata (like in ARC-69).

It is a question of definition. The Int(0) index is usually considered outside of those arrays and is a special case.

Not to my knowledge. However, it is important to remark that on Algorand those patterns are most of the time not required. Indeed, contrary to Ethereum, applications can be updated and right to update is controlled by the application itself.

1 Like

Details of the protocol are provided here: GitHub - algorandfoundation/specs: Algorand Specifications

1 Like

Thank you for your detailed feedback :pray: