Context: I have a voting application with 1,000 voting options, meaning the voters have 1,000 options to choose from.
Problem: The global state is limited to only 64 key-value pairs, I want to get around this.
My first thought was to create 64 accounts and rekey them to the smart contract. Then I can use their local state as a “global state”. If every account has up to 16 key-value pairs for local state, then I would have 16 * 64 - 64 = 960 key-value pairs total.
Question 1) Is this approach feasable?Question 2) Are there any better ways to do this? Perhaps a technique that allows me to fit over 2,000 options?
Ben
April 25, 2022, 7:30pm
2
You may be interested to read this document: wormhole/MEMORY.md at algo/integration · certusone/wormhole · GitHub
That said the design for unlimited or box storage is in progress this quarter
Ben
1 Like
Hey please tell me if this solved your issue of storage?
The up to date link is:
# Algorand memory allocation
# Table of Contents
1. [Background](about:blank#orgea5c5c2)
2. [The “allocator” program](about:blank#org85bc975)
1. [Instantiating template variables](about:blank#orgf176818)
1. [Instantiation, off-chain](about:blank#org2091dfe)
2. [Instantiation, on-chain](about:blank#orga6fa146)
2. [Allocating, client-side](about:blank#org74c4227)
<a id="orgea5c5c2"></a>
# Background
The Algorand blockchain has a completely different virtual machine from the other chains Wormhole currently supports. The assembly language of Algorand is called TEAL, which runs on the Algorand VM (AVM). This means that understanding the Algorand contracts will require understanding a whole new set of platform-specific features and constraints.
The purpose of this post is to investigate the way the Wormhole contracts handle (or rather, implement) memory management on Algorand. This is particularly interesting because of the unique memory constraints on this platform which require a fair amount of creativity to overcome. This code is critical, and highly non-trivial.
Like EVM bytecode, TEAL is a purpose-designed instruction set, but unlike EVM, there is currently no high-level language (like Solidity) with a compiler targeting TEAL. There is an in-between solution, called pyTEAL. pyTEAL is **not** a compiler from Python to TEAL, instead, it is an embedded domain-specific language for generating TEAL code in Python. This means that each pyTEAL program is a code generator (it’s a heterogeneous two-stage programming language). The thing about multistage programming languages is that you always have to think about when a piece of code will execute - compile time or runtime? We’ll discuss this in detail.
show original
This is currently the best option if you cannot wait for boxes that should come soon and bring unlimited global storage to Algorand.