Adversarial Pair Programming

Posted by: Poster Image

Summary Argument: In traditional pair programming, two trusted developers are assigned to work jointly on writing sections of software. This article explores an adversarial pair programming concept where two anonymous developers code together under the assumption the other person is malicious.  926 tokens
Agree Disagree
Loading

Celody generates a private key for you to access withdrawn tokens. If you lose this key, you will lose access to your tokens. So keep it safe! Celody does not store these keys.

tokens Generate New Key Use Existing Key
tokens Start Deposit
tokens Start Transfer
Export to AVAX C-Chain Import from AVAX C-Chain

Submit Address

Celody will transfer tokens to address:

tokens Submit Token Amount
Submit Address

Celody will receive your tokens from address:

tokens Submit Token Amount

You have 10 minutes to make ONLY 1 transaction.

10:00

Send CLDY tokens from address (0x000...) to address: 0x0000000000000000000000000000000000000000

After sending, click the "SENT" button below:

Tokens Sent
Admin Review

Enter transaction hash for confirmation:

Back to Menu
     In traditional pair programming, two developers are assigned to work jointly on writing sections of software. The use of two people instead of one brings certain benefits. The code gets double-checked for bugs and gains from the expertise of two brains. Of course, there are the added costs of two people instead of one.
     In traditional pair programming, the two developers trust one another. They are known to one another and perhaps even self-select the pair themselves. The trust between the two developers assumes that the code won't be malicious. One developer assumes the other won't insert a backdoor virus. But what if two anonymous developers wanted to code a project without trusting the other?
     If you are paired with another developer who you don't know, like in an open source project that accepts remote commits, you have to assume that all actions could possibly be malicious. Now in a traditional open source project, there isn't really pair programming. It's more of a review system, where individuals develop the code and then authorized users can accept these pieces. But the practice could be extended where two anonymous developers code together and each assumes the other could be malicious.
     One of the mechanisms to ensure that the code is not malicious is to require a token deposit from both people. Such that if a person finds malicious code, the other person could be penalized by having their staked tokens slashed. The actual process could be more sophisticated where the programming pair could have a system of other pairs that review each other, where the incentives to slash increase as more reviewers are added.
     So how could adversarial pair programming be structured? First, everyone in the group would have to agree on the architecture of the code. The entire code base would have to be outlined at a high level and broken into groups. Then those fragmented groups would have to be assigned to random pairs. And then those random pairs would be randomly assigned to have reviewers.

Staked: 926 tokens

Slash Date:

Staked:
926 tokens

Slash Date: