Multi index tables reading permissions

[sergioyuhjtman]

Even though multi index tables are necessarily public from outside the chain, it might be useful a feature allowing to block other smart contracts from reading the table. This would allow for example micropayments for direct access to a table from a smart contract, expanding the universe of possible apps.

[jgiszczak]

There are no plans to restrict readability of multi-index tables to contracts. Such restrictions would be terribly misleading, convincing people of the presence of data privacy where none exists.

[sergioyuhjtman]

@jgiszczak Yesterday @bytemaster said it is a "potential good idea" at telegram. I know it is a good idea, because I thought about it. Please reopen the issue.

[sergioyuhjtman]

@jgiszczak This is not about data privacy, it is about on-chain permissions

[wanderingbort]

Hi @sergioyuhjtman,

We can re-open this issue as a platform for healthy debate on the feature. If there is no consensus or active discussion after 14 days we will close the issue.

What I can say is that this would be a hardfork feature so, I have labeled it as such. This means that the critical path for activating such a feature to an EOSIO-based blockchain is the governance of the individual blockchains, not the development of the feature.

In an effort to conserve development resources there would have to be pretty clear consensus from existing/future deployments of EOSIO-blockchains that this has value. Otherwise, we cannot prioritize it in development at this time.

Please invite any perspectives you find in the various EOSIO-based communities to come represent themselves on this issue.

[wanderingbort]

From my perspective, this feature enables a market for convenience of on-chain data access from contract. As the data is public, any contract can set up a process to submit a copy of the given data, via an "oracle" that the contract trusts, to a table which has no access restriction.

This means that the naive upper bound of the value of this feature is

• the expense of running an oracle, which can be amortized across all "pirate use cases"
• the expense of publishing a copy of the required data from a chain resource perspective
• the expense associated with the latency of creating the "pirate copy"
• the risk that the "pirate copy" will be abandoned

As it is impossible to add a Ricardian contract to data access at this time, there is no way to artificially increase this value by imposing a contractual penalty (via arbitration) to un-licensed access.

There could be a constitution/terms of service level obligation to respect these data rights and penalize unauthorized copies however, that requires a far larger community consensus.

My opinion is that this presents a diminishing return on the value of the feature. The more valuable the data the more attractive amortized piracy becomes and therefore the profit margin on the data access will approach zero.

[sergioyuhjtman]

@wanderingbort Thanks. I agree on your approach to analyze the feature. However I think you are missing the central advantage of the feature: an extra oracle means an extra layer of trust. That's why the primary source is definitely more valuable than any copy of it.

[conr2d]

@sergioyuhjtman Can you elaborate a use case such as your example (micropayments that require blocking access from other contract)? It looks like an interesting idea, but I cannot get what new apps are possible by this feature intuitively.

[sergioyuhjtman]

@conr2d I am thinking in a decentralized oracle. This would be the easiest way to monetize the oracle as a service. A mere copy of the table would turn it centralized.

[sergioyuhjtman]

@conr2d @wanderingbort @jgiszczak Consider an oracle whose only task is to feed into the blockchain some public and easily accesible data from the web. This service has to gain reliability by some means, and it is reasonable to expect a market reward for this service. Then, for a second oracle would be the same cost to copy the first oracle table, or to copy the primary data from the web. So in this case, it makes perfect sense to ask for a payment in exchange for on-chain reading. The service that is being provided is just the reliable feed into the blockchain.

[wanderingbort]

an extra oracle means an extra layer of trust

I don't actually agree. In this case, the blockchain presents a provable version of this extra oracle in that you can copy-paste the wasm code to a new account, then re-submit the transactions that were sent to the authentic oracle with a delay to the clone. All of this can be done in a way where there is no added trust, only added latency (potentially infinite latency).

I have edited my bullet points to reflect the cost of that latency and the risk that the verifiable copy stops receiving updates.

[sergioyuhjtman]

@wanderingbort I would like a clarification on this: "re-submit the transactions". Can this be done automatically by a smart contract? (I don't think that is even possible. If it is possible, then I agree that it is useless to block tables readability). Otherwise, you are trusting someone new to do it faithfully.

[wanderingbort]

you are trusting that anyone will submit them. The transactions (and ordering) can be proven to a block header via the transaction merkle root, the blocks can be proven as a light client. Essentially this is IBC from a chain to itself. It is certainly not free, perhaps not even cheap in the current state but that all falls under "the expense of running an oracle...". It does not require additional trust to verify the data.

Generally my stance is that monetization enabled by this feature is valued only by user-convenience. I will agree the feature proposed is far more developer-convenient than the suggested alternatives and that this will affect the pricing. However, it does not provide any additional trustworthiness over methods which circumvent the feature.

So, if the circumvented feature achieves the same user-convenience at a lower user price, then the value of the feature will drop to zero.

I think this means the cost of creating/farming the original information must be less than the cost of maintaining the unauthorized access solution(OAS) otherwise, the OAS will win the pricing war. Since the cost of copying an OAS should approach zero over time (after all the solution itself can by "pirated"), the sustainable price an authentic service can pay for creating/farming the information will also approach zero.

[sergioyuhjtman]

@wanderingbort From my very limited understanding (after partially reading the documentation), I feel that you are saying that it can be very easily verified by anyone that both tables coincide. That was granted from the beginning. However, that is not the same as an automatic on-chain verification made by a smart contract.

Sorry if I am misunderstanding, and your method actually performs such a verification. But otherwise let me know, so maybe I can drop further arguments.

[wanderingbort]

What I'm suggesting is that there is no trust required to have a second contract recreate the tables that are protected. It cannot be automated by a contract alone but the process by which data is fed into the second contract can be automated and does not require trust.