A cryptographic "discipline" ladder.

We drew this after losing two pilot partners by being overzealous researchers. 

(1 / N)

founder @seismic // product-focused cryptography // rookie years @ stanford, google

The @seismic team is full of privacy maxis. 

As such, whenever a pilot partner joined our first cohort, we'd go crazy on their codebase. 

HIDE IT ALL was our gut reaction for every protocol.

"You should hide X to create this mystery, Y to ensure zero leakage, and obviously Z because users don't want that information out there."

"We can use attribute-based encryption to do this, a kernel function to do this, and fully homomorphic encryption to do this."

Theory people loved this system.

Our actual customers on the other hand? Dropped us on multiple occasions.

I don't blame them. Dapp UX after Seismic integration was horrendous. 

Bloated client distro packages. Dependency hell for every upgrade. 15s+ tx construction time (longer than mainnet block times).

What were we doing wrong? We were undisciplined.

Whenever someone asked us for a mechanic, we never took the time to understand exactly what data they needed to blind and why.

What we thought a hard question looked like: "How do we prevent any PPT adversaries from learning this action taker's identity?"

What a hard question actually looked like: "Why do we care about shielding the identity?"

Often times, the answer to the real questions was that we shouldn't care.

Turns out that shielding is unnecessary for 90% of all the mechanics we implemented. Why hide a game character's [location, inventory, spells, identity] when [location] provides the same strategic depth?

When we realized this, our mindset shifted from hiding as much as possible, to hiding as little as possible.

We instituted the discipline ladder to enforce this learning. It goes from the least complex (keep var public) to the most complex (partially homomorphic encryption).

Now, whenever we work with a new partner, we're strict about starting at the bottom rung.

Prior to going up a rung, we take a hard look at the problem. 

Are we sure this addition is critical to the end user experience? Are we sure we can't use any prev rungs in a creative way?

After starting this practice, our system started flying.

Proving time went down to milliseconds. Client side packages shrank by orders of magnitude. Integration times reduced from months to weeks.

Customers were happy.

This ladder completely changed the way we operate as a company.

It shifted the focus away from our intellectual needs (irrelevant) and toward customer needs (relevant).

And that's the down-low on our discipline ladder. Would highly recommend for anyone working in applied cryptography.

Only told the story around it in this thread. Will talk about the actual contents sometime soon.

We liked math and engineering. Not product.

It was easier for us to say "blind it all" instead of taking the time to actually understand product goals.