kleros/tcr

Arbitrable Permission Lists on Ethereum

Arbitrable Permission Lists on Ethereum

Contracts for creating arbitrable permission lists on Ethereum.

Development

1. Clone this repo.
2. Run yarn install to install dependencies and then yarn build to compile the contracts.

Release

To bump the version of the package, use yarn release.

Scripts

• yarn prettify - Apply prettier to the entire project.
• yarn lint:sol - Lint the entire project's .sol files.
• yarn lint:js - Lint the entire project's .js files.
• yarn lint:sol --fix - Fix fixable linting errors in .sol files.
• yarn lint:js --fix - Fix fixable linting errors in .js files.
• yarn lint - Lint the entire project's .sol and .js files.
• yarn test - Run the truffle tests.
• yarn cz - Run commitizen.
• yarn build - Compiles contracts and extracts the abi into the abi folder.
• yarn release - Run standard-version`.

Test

Testrpc default gas limit is lower than the mainnet which prevents deploying some contracts. Before running truffle tests use: testrpc -l 8000000.

Testing contracts

• Run npx hardhat compile to compile the contracts.
• Run npx hardhat test to run all test cases in test folder.
• Run npx hardhat test <location of test file> to run the test cases for specific contract.

Testing contracts on specific network

• Run npx hardhat test --network <network name in hardhat.config.js> to run all test cases in test folder.
• Run npx hardhat test <location of test file> --network <network name in hardhat.config.js> to run the test cases for specific contract.
• Add private keys for the roles needed to test the contracts according to hardhat.config.js.

Contributing

See contributing.

Learn how to develop arbitrable and arbitrator contracts here.

tcr's Issues

Remove useless assignment

tcr/contracts/GeneralizedTCR.sol

Line 312 in b45e9cc

round.feeRewards = round.feeRewards.subCap(arbitrationCost);

This line does nothing since feeRewards at that point is always zero.

Add evidence curation support

The scheme below is not backwards compatible. We can build a system that is backwards compatible with arbitrable contracts already deployed.

# Summary

We can use the Generalized TCR contract to build an evidence section visually similar to reddit's comment section. Additionally, evidence submission can require a deposit such that anyone can challenge it.

To do this, we add a new field address evidenceTCR to the request struct. We update challengeRequest() to also:
1- Deploy a new GTCR contract;
2- Save its address in request.evidenceTCR;
3- Call evidenceTCR.addItem with _evidence

Additionally, we update the constructor() to accept parameters that will be passed to the constructor of the evidence TCR.

### Example
Consider a Token TCR at a given point in time:
challengeBaseDeposit: 1 wei
evidenceChallengeBaseDeposit: 1 wei

A user challenges a request, which which deploys the evidence TCR. For the constructor parameters, the evidence arguments are passed such that child evidence disputes will have the same context as the parent:

request.evidenceTCR = new GeneralizedTCR(
    ...,
  evidenceChallengeBaseDeposit, // This will be stored in challengeBaseDeposit
  evidenceChallengeBaseDeposit, // This will be stored in evidenceChallengeBaseDeposit
   ... 
);

This way, the price to challenge a token submission is different than the deposit to challenge the evidence of a token submission dispute. However, the deposit to challenge evidence related to the token dispute will be the same no matter how deep in the tree it is.

## Note on EIP-170
The queryItems function was added to the GeneralizedTCRView contract, which means we can remove it from the GeneralizedTCR contract if the above modifications cause the bytecode to go over 24.5kb in size.

---

https://forum.kleros.io/t/feature-request-ability-to-mark-evidence-as-fake-news/247/3

Provide some info / context about infrastructure that runs scripts to execute requests

tcr/contracts/GeneralizedTCR.sol

Lines 432 to 437 in 72e547e

	/** @dev Executes an unchallenged request if the challenge period has passed.
	* @param _itemID The ID of the item to execute.
	*/
	function executeRequest(bytes32 _itemID) external {
	Item storage item = items[_itemID];
	Request storage request = item.requests[item.requests.length - 1];

I understand what's going on.

Submitted item.

Not challenged.

Can move to the list.

BUT

I think there is some automation script.

I would like to know more about it... How often does it run?

Lock meta evidence to request

Currently the TCR contract takes the latest meta evidence when a dispute is created. This is not the best situation as someone can put a request and then get challenged based on new meta evidence.

To fix this we need to save the meta evidence in the request struct and then use that as the dispute meta evidence.

Is there a way of knowing if the item has been added and then subsequently removed?

tcr/contracts/LightGeneralizedTCR.sol

Lines 32 to 37 in 72e547e

	enum Status {
	Absent, // The item is not in the registry.
	Registered, // The item is in the registry.
	RegistrationRequested, // The item has a request to be added to the registry.
	ClearingRequested // The item has a request to be removed from the registry.
	}

It seems to me that Absent is not conclusive?

Is there a convenient way of iterating through the list?

Generalized:

Here yes:

tcr/contracts/GeneralizedTCR.sol

Line 94 in 72e547e

bytes32[] public itemList; // List of IDs of all submitted items.

Light version:

Here no:

tcr/contracts/LightGeneralizedTCR.sol

Lines 122 to 125 in 72e547e

	mapping(bytes32 => Item) public items; // Maps the item ID to its data in the form items[_itemID].
	mapping(address => mapping(uint256 => bytes32)) public arbitratorDisputeIDToItemID; // Maps a dispute ID to the ID of the item with the disputed request in the form arbitratorDisputeIDToItemID[arbitrator][disputeID].
	mapping(bytes32 => mapping(uint256 => DisputeData)) public requestsDisputeData; // Maps an item and a request to the data of the dispute related to them. requestsDisputeData[itemID][requestIndex]
	ArbitrationParams[] public arbitrationParamsChanges;

GTCR Factory: Allow upgradable contract code.

Currently the GTCR Factory simply keeps a copy of a version of the GTCR and deploys it. This has the downside that the version of the GTCR code to deploy is locked. New versions would require a new factory.

Instead, we can have the factory store the address of a GTCR instance. deploy() would then copy the code and deploy from that.

If the GTCR code is ever updated, we can update the address of the "blueprint" GTCR so that new versions can be deployed using the same factory.

Write tests for GeneralizedTCR.sol

We are missing automated tests for it.

Verify code on Etherscan for Goerli

Here are the addresses: https://github.com/kleros/gtcr/blob/master/.env.example#L7

REACT_APP_DEFAULT_TCR_ADDRESSES={"42":"0x6e94b7b0340f25C3D2BfE59aeB688f489aD7c1e0","1":"0xba0304273a54dfec1fc7f4bccbf4b15519aecf15","4":"0x359cf635d3a7dc742346e6b965783e02594bc102","5":"0x445eceA26d5ec40E177e6Ca2734821D8430a9C1A","100":"0x2442D40B0aeCad0298C2724A97F2f1BbDF2C2615","421611":"0x7971Ef3839D6199c5fF296E7f1a53d56aCE9145b"}

42 is Kovan - verified - https://kovan.etherscan.io/address/0x6e94b7b0340f25c3d2bfe59aeb688f489ad7c1e0#code

5 is Goerli - not verified - https://goerli.etherscan.io/address/0x445ecea26d5ec40e177e6ca2734821d8430a9c1a#code

EDIT:

Verified after all?

https://goerli.etherscan.io/address/0xc20017aec4a410ac4636aebb6032b4eb3980bee7#code - from Etherscan transaction history, not .env file

Unnecessary fee stake for challenge and submission

requestStatusChange and challengeRequest currently require that the user also includes the fee stake. Since there is no crowdfunding in the first round this is useless and makes requesting and challenging more expensive.

Additionally, when the arbitrator refuses to rule a dispute of a single round (no one ever appealed) the costs should be split such that each party pays 50% of the arbitration costs. There should be no ETH leftover in the contract.

See branches feat/first-round-fee-stake and fix/ruling-none-fees

Implement GTCR Factory

[Bug Bounty: up to 100 ETH] Generalized Token Curated Registry

Generalized Token Curated Registry Bounties

This is a bug bounty on the generalized token curated registry contract and its factory contract.
Bugs are rewarded up to 100 ETH according to this classification:

• Critical Bugs: 100 ETH
  for bugs that enable stealing a high amount of user funds or add malicious items to the registry.
• Major Bugs: 50 ETH
  for bugs that can lock user funds or enable stealing a low but non negligible amount of user funds or remove legit items from the registry.
• Minor Bugs: 5 ETH
  for smaller bugs which can still produce a non negligible amount of harm to users.

Those contracts are already deployed. If you find a bug you can send a bug report to [email protected]. Do not submit a vulnerability there before getting the written agreement that a submission can be done or that your vulnerability has been rejected. This is in order to let us fix potential issue before they go public. Reports made public before us having time to respond would not result in payment of rewards. In case of dispute about the classification of a bug, Kleros will be used to resolve it.

Generalized Token Curated Registry

The generalized token curated registry is a curated list which can be created by users from a simple graphic interface.

• There is a factory to create curated registries.
• A requester can request an item to be added by putting a deposit.
• If no one complains within the time limit, the item is added and the deposit refunded.
• A challenger who believes this item does not belong to this list can pay a deposit, this creates a dispute.
• An arbitrator will settle this dispute.
  • If the arbitrator rules for the submitter, the item will be added and the submitter will get the deposits minus arbitration fees.
  • If arbitrator rules for the challenger, the item will be removed and the challenger will get the deposits minus arbitration fees.
• There is an appeal mechanism.
  • There are appeal fees. A deposit must be paid by each side. The deposit of winning side is reimbursed. The deposit of the losing side is used to pay arbitration fees and to compensate the winning side.
  • The side currently losing must pay its fees during the first half of the appeal period.
  • If a side does not pay its fees, it is assumed to have lost the dispute.
• Items can be removed through a similar mechanism.

Bounty

Smart Contract Guidelines

We use those guidelines to write smart contracts. In particular, we do not try to prevent stupid behaviors at the contract level but leave this task to the UI. Letting the possibility to a user to harm itself is not a vulnerability (but should of course be dealt at the UI level).

Violation of guidelines are not vulnerabilities but can be reported as "suggestion for tips" (you may get a few PNK for it).

Bounty Rules

• If you have any questions, don't hesitate to ask on the slack channel (slack.kleros.io #smart-contract-review) or by sending a mail to [email protected] .
• This bounty may be advertised on multiple platforms. Bounties are only awarded to the first person finding the bug irrespective of the platform.
• All this code is provided under MIT license and can be reused by other projects. If you do, don't hesitate to inform us and we may list your deployed contracts in the @deployed of the RAB pragma.
• Good luck hunting and have fun hunting!

Deployment on Arbitrum Rinkeby

Is _registrationMetaEvidence and _clearingMetaEvidence available on-chain?

It appears to me that event is emitted:

• available on the front-end (can listen to events)
• not available on-chain (cannot listen to events)

tcr/contracts/LightGeneralizedTCR.sol

Lines 781 to 819 in 72e547e

	/**
	* @notice Changes the params related to arbitration.
	* @dev Effectively makes all new items use the new set of params.
	* @param _arbitrator Arbitrator to resolve potential disputes. The arbitrator is trusted to support appeal periods and not reenter.
	* @param _arbitratorExtraData Extra data for the trusted arbitrator contract.
	* @param _registrationMetaEvidence The URI of the meta evidence object for registration requests.
	* @param _clearingMetaEvidence The URI of the meta evidence object for clearing requests.
	*/
	function changeArbitrationParams(
	IArbitrator _arbitrator,
	bytes calldata _arbitratorExtraData,
	string calldata _registrationMetaEvidence,
	string calldata _clearingMetaEvidence
	) external onlyGovernor {
	_doChangeArbitrationParams(_arbitrator, _arbitratorExtraData, _registrationMetaEvidence, _clearingMetaEvidence);
	}
	/* Internal */
	/**
	* @dev Effectively makes all new items use the new set of params.
	* @param _arbitrator Arbitrator to resolve potential disputes. The arbitrator is trusted to support appeal periods and not reenter.
	* @param _arbitratorExtraData Extra data for the trusted arbitrator contract.
	* @param _registrationMetaEvidence The URI of the meta evidence object for registration requests.
	* @param _clearingMetaEvidence The URI of the meta evidence object for clearing requests.
	*/
	function _doChangeArbitrationParams(
	IArbitrator _arbitrator,
	bytes memory _arbitratorExtraData,
	string memory _registrationMetaEvidence,
	string memory _clearingMetaEvidence
	) internal {
	emit MetaEvidence(2 * arbitrationParamsChanges.length, _registrationMetaEvidence);
	emit MetaEvidence(2 * arbitrationParamsChanges.length + 1, _clearingMetaEvidence);
	arbitrationParamsChanges.push(
	ArbitrationParams({arbitrator: _arbitrator, arbitratorExtraData: _arbitratorExtraData})
	);
	}

Or maybe there is some other way and I'm missing something?