computablelabs / compspec Goto Github PK

It is possible for attackers to front-run large calls to Reserve.support to take advantage of large in-bound patron fees. The attackers can buy them immediately sell via Reserve.withdraw. If the boost in price is larger than spread, this attack can be profitable. Suggest that patrons either:

• Use a high gas fee to discourage front running
• Break support calls into smaller chunks for security

From v0.3 of the protocol spec:

Major decisions in the Market are made by token holder vote...A threshold T_council will be imposed, and only MarketToken holders who hold more than T_council units of MarketToken will be allowed to vote.

Qualitatively, this creates two mechanisms for making decisions. When T_council is 0, the market functions like a direct democracy with all token holders able to cast decision making votes. When T_council > 0, the market functions like a private company with a class of active shareholders with decision making power and a class of passive shareholders without decision making power. The only mechanism to transition from passive to active is by increasing token ownership.

Some markets may benefit from a decision making system analogous to public companies and representative democracies, where decision making power is reversably pooled by token holders to rest in a small set of individuals who make decisions and are accountable to their token-holding "constituents". This "elected" group would be akin to a board of directors or legislature.

Such a scheme may be useful in markets with long tails of ownership (perhaps through long tails of crowdsourced data contribution) and / or diverse demand-side uses where a diverse and potentially competing set of goals for the data market co-exist.

Such a scheme may also be a powerful proposition to crowdsourcing data listers who desire equity and decision making power in proposition to token ownership but do not want to or does not have the ability to vote on every decision individually.

An example implementation could involve minting a token tuple (e, v) where the e token is held as ownership stake / equity, and the v token is used for voting. The v token can be reversibly lent to another address to allow that address to vote as a proxy.

There are a number of high level questions we should start answering about queries. This issue lays out a first spike to start getting some query support into computable backends:

1. What does a query look like?

• For now, this will probably just be a subset of SQL, but we need more detail on the specific subset. Is this the subset supported by Athena?

2. How can we get a query from the user to the backend system?

• For example, is this through an ORM? Or even simpler, does the user send a raw SQL file over? Is there a REST endpoint the user sends the file to?

3. How do we validate the query?

• Are there standard query sanitization tools? We should likely use Athena or SQLlite immutable or a similar system to make sure query isn't dangerous.

4. How do we get Flex set-up?

• https://github.com/uber/sql-differential-privacy is Uber's differential privacy tool, Flex, for SQL. How can we get this up and running on the backend?

5. How can we compute privacy parameter epsilon for a given query?

• Specifically, how do we run Flex on a given query

6. How do we send results back to the user.

Talk through the contingency plan if a market is bricked. How market members can migrate to a new market and make a "fork recipe"

It's possible for cost_per_byte to change between the time the user submits Datatrust.requestDelivery call and the time the call is confirmed. This means that the user could end up paying an unexpectedly high price for the data. Document this issue and suggest that the user offer high gas fees to enable rapid confirmation or break up orders into multiple smaller orders to avoid issues.

Currently, the EtherToken chapter says:

You will need EtherToken for all your interactions with the Computable smart contracts

Comment by @robrobbins:
"not true. in almost all cases you need CMT. CET is only ever used to support or as an eventual exit"

We should add a page about purchasing data that explains the mechanics of the delivery process. The existing Datatrust page introduces the concept but doesn't really go into it in sufficient depth. This should explain how the bytes purchased from multiple deliveries pool together.

From the protocol:

The votes here are not stake-weighted. All council members have precisely one vote. So a council member with 5*T_council and another council member with 1.1*T_council MarketTokens have the same voting power.

This allows for a sybil style attack where a council member with 5.5*T_council tokens distributes them to 5 separate addresses each with 1.1*T_council tokens and gains 5 votes in the council.