I’m working on a project in nodejs and my scenario is like this:
I run a local node on my mac and I plugged my algosdk to it
I watch for every new block with algosdk in my script
right when I receive a new block, I read data from an Algorand application state, I perform a series of operations in my script relative to the application state I just retrieved, prepare group transactions and then send them to the network
The thing is, I’m often too slow (I think?) and some of my transactions are sometimes rejected by the application because its state I read from the previous block is no longer true when I submit my transactions.
My question is:
How can I improve my speed so I can be sure that my transactions are going to be the first in line in the next block, and then ensure the application accepts them?
The official participation nodes include the transactions in the block in the order they see it.
If you have a very good connection to the network and if you select properly the relays, you may get the new block slightly in advance.
Furthermore, you could in theory modify the Algorand software to output a guess of the next block slightly in advance (before it is actually voted in and officially added to the blockchain - so you cannot be 100% sure that will be the correct block but you can have a good guess). But this is very advanced.
Are you trying to frontrun another transaction or are you developing a dApp that requires to know the transactions in the previous block?
In the latter case, you may need to change the design of your dApp to reduce this issue that can limit the throughput of your dApp.
Reading the description of that task you’re trying to accomplish, it sounds like you’re trying to compete with other actors on the blockchain. If you’ll try to multiply that to multiple actors, this would clearly fail for most, right ?
Keep in mind that if you’re sending a transaction on round [ x ], it would not be included before round [ x + 2 ] ( i.e. by the time you’re seeing committed round [ x ], round [x+1] is already being agreed upon, so no new transactions would go there ).
I would suggest that you’ll try to build the logic so that it won’t be dependent on the global state of a single round, but rather the last state of the application. Also, try to separate the global app variables being “touched”, so that client-transactions would use one set, and “server” transactions would use another.