When first knowing about Bitcoin, and understanding it, I remember the umbrella of possibilities that I thought about as a developer.

Unfortunately, Bitcoin’s limited scripting and its UTXO model weren’t enough to cover all that a developer’s imagination can think about. Later on, thanks to Ethereum and its programming languages like Solidity, that imagination was unleashed.

We could finally build fully fledged dapps without requiring any trust to the user, because the previously existing intermediaries could be replaced by self-enforcing smart contracts.

But smart contract development is quite different from traditional development. There are things you can’t do, and things that are confusing. As an example, many of the applications we receive for the Solidity developer opening at Aragon come from very qualified people, but some of them appear to think that adding a private modifier to any function suddenly makes that function and its execution invisible to the world. Unfortunately, in the blockchain, you cannot do that. It doesn't magically protect the bits of code that you'd like the world not to see, nor it safeguards that private key you would like to safeguard for your dapp to work.

That’s a shortcoming that makes it hard to build a ton of applications that require secure private computation, including anything that has to do with doing encryption and decryption of private data.

One of my favorite examples is a dead’s man switch (DMS). The ability to release certain information or certain keys given lack of interaction within a timeframe is perfect. Traditional DMS rely on central point of failures, such as servers or other kind of infrastructure, that needs to be maintained, kept secure (eg without backdoors) and paid for regularly, usually breaking anonymity. If built using a blockchain, a DMS becomes fully unstoppable, even by nation-state actors or other potentially malicious actors, and can be fully anonymous.

However, building a DMS in Ethereum is tricky. You would generally want a DMS to do the following:

Enable a way to check-in routinely, and log check-ins so you know how much time has passed since the last one If the time passed > a threshold, do something The action to be triggered could be releasing some encrypted information to determinate receivers, or just decrypting some previously encrypted information and releasing it to the world

1 and 2 are trivial to build. You can store a timestamp within the contract, and expose a method which increases it, such as follows.

uint public lastCheckin;

event Checkin(uint time);

​

function checkin() onlyOwner returns(bool) {

lastCheckin = now;

Checkin(now);

return true;

}

But, for 3… it’s complicated. The information you want released should be secret before the moment of its release, therefore it must stay encrypted. But how do you decrypt it when the moment comes, if the private key owner is not accessible anymore, and without requiring any third party centralized actor?

There’s no easy way to enable that funcionality, but back in 2014 Vitalik described multiple fundamentals that could make it possible, and the groundbreaking applications that a system like that would have.

Fast forward to today and… meet Keep! Keep uses the same fundamentals Vitalik described (SMPCs) plus an incentives layer to make sure nodes in the Keep network stay financially incentivized not to steal the keys in the keeps.

Keep extends blockchain programming by adding a privacy layer: you can now count with private data and all the power public key cryptography gives you, on-chain.

With Keep, step 3 would be easy. You could create a keep, and then request the decryption of that keep when (lastCheckin + threshold) - now < 0 . Your valued information would be relesed decrypted to the world, and that's it! We have just closed the circle for building a DMS.

And there are many other applications that are possible with Keep. One of them that we are particularly excited about at Aragon is having encrypted data vaults controlled and owned by DAOs. This would enable private data to be shared with selected stakeholders, which could be added or removed depending on the DAO’s governance mechanism.

If you are a developer, please take a look at Keep’s whitepaper. Once you understand how it works, it will become a very powerful ally in your toolbox, and naturally extend your thinking on the things you can build on a blockchain.

I’m very excited to build on Keep!