Lookup tables - space vs processing time tradeoff

yoyoyoyo Member Posts: 34 ✭✭
Many expensive computations can be precomputed and stored in lookup tables.
It's relevant for example for logarithms, square roots, sine, etc.

The community of Ethereum contract developers could agree to store specific lookup tables in well identified contracts with a well defined structure.
These contracts would be read-only, after the initial creation, the contract would not answer to any input and wouldn't have any code to run, to ensure the tables remain static.

External contracts could then extract relevant information from the table with minimal fee (`Extro` instruction) instead of performing the costly computation.

The initial storage cost could be large but can be shared among several contributors, (possibly competitors), with end benefits for all.

Comments

  • yoyoyoyo Member Posts: 34 ✭✭
    edited January 2014
    In a similar trend, an individual contract could implement a kind of memoization.

    When performing a very processing intensive (costly) computation, it could store the parameters and result in a cache in permanent storage.
    When a similar computation arise in a later transaction, it could first check if it already knows the result.
    This would work well for a range of problems with recurring costly computations with the same parameters.

    If we have an estimate of the probability to hit the cache and we know the cost of lookup vs cost of operation, it is possible to assess the profitability of this strategy for a given problem.

    If several contracts implement the same operations, they could use a common repository for storage, by way of a third party contract storing these cached results. It is less pure than the static lookup table of my previous post but it could work for more advanced functions implemented by a group of mutually trusting contracts.
  • FreddyFenderFreddyFender Member Posts: 39
    My plan is to leave many extenuous calculations and data (pre)reconfiguration on a platform such as OT where it can remain encrypted and code is obfuscated and not directly tied to Ethereum contracts. Ethereum does the blockchain duties of veracity and OT (or other such structure) can handle contract interactions.
  • yoyoyoyo Member Posts: 34 ✭✭
    That's a solution but then you have to pay for resources yourself and the contract is not self-sustained anymore. A truly autonomous contract is more desirable IMHO, the service provided should fuel its own costs to the larger extent possible.
  • yoyoyoyo Member Posts: 34 ✭✭
    That's a solution but then you have to pay for resources yourself and the contract is not self-sustained anymore. A truly autonomous contract is more desirable IMHO, the service provided should fuel its own costs to the larger extent possible.
  • FreddyFenderFreddyFender Member Posts: 39
    What if the autonomous contract resides in ethereum and the method of calling transactions is a separate series of static contracts (table lookups included) that modify based on the many states the initiating autonomous contract requires? I wish to limit what entities may call (tx) to assure secure code of client SW.
  • FreddyFenderFreddyFender Member Posts: 39
    What if the autonomous contract resides in ethereum and the method of calling transactions is a separate series of static contracts (table lookups included) that modify based on the many states the initiating autonomous contract requires? I wish to limit what entities may call (tx) to assure secure code of client SW.
Sign In or Register to comment.