In #14595 and related work, we're abusing capsule arrays to pass arbitrarily sized arrays back and forth between contracts and PXE. This is fine in terms of API and behavior, but is not fantastic performance-wise since it means we're creating tons of database transactions for things that have no proper database requirements, including persistence, atomicity, etc.
We should instead introduce a volatile store that only exists during a contract's execution (and is inaccessible during child simulations, and removed once the current simulation ends). This would just be a memory array, which means that the entire cost of the abstraction is that of calling oracles. Since this would not be an arbitrary kv-store but rather array-specific, it might make sense to create oracles with array semantics (e.g. push and pop so that we have single oracle calls instead of read for len, write for new elem and write to update len).
In #14595 and related work, we're abusing capsule arrays to pass arbitrarily sized arrays back and forth between contracts and PXE. This is fine in terms of API and behavior, but is not fantastic performance-wise since it means we're creating tons of database transactions for things that have no proper database requirements, including persistence, atomicity, etc.
We should instead introduce a volatile store that only exists during a contract's execution (and is inaccessible during child simulations, and removed once the current simulation ends). This would just be a memory array, which means that the entire cost of the abstraction is that of calling oracles. Since this would not be an arbitrary kv-store but rather array-specific, it might make sense to create oracles with array semantics (e.g.
pushandpopso that we have single oracle calls instead ofreadfor len,writefor new elem andwriteto update len).