← Back to Blog

Weekly Project Update #6

The one where I explore how to do things off-chain

2 min read • BD Tinsley

Overview

Without really having a plan for what I'm about to write, I can feel that I'm going to write a lot. The last few weeks have been somewhat murky in terms of where I thought I'd be and where I have to be. To sum it up, I was off in my initial project plan by thinking that hashing and encrypting did the same thing. Hashing is a one way function, meaning whatever you hash cannot be reversed to regenerate whatever is stored there, while encrypting is. Solidity, the language for building contracts on Ethereum, has built-in hashing, but not encryption. Encryption must be done off-chain.

A real quick note about "on-chain" vs "off-chain" in case you are unaware: the chain in this scenario means blockchain, and any operation done on-chain means the person, or sender, of the contract is paying for the computing as it is done on the Ethereum network as a gas fee. Because encryption algorithms cannot be run on-chain, it means I've got to come up with a solution to figure out where the computing needs to happen. Some ways people handle this is running some decentralized app (dApp) that integrates with the contract, or sometimes a centralized app running on AWS or Heroku. The ultimate goal of decx.press is to bypass any centralized application and building a dApp feels like it would be a big ticket item. So I am electing to build out a minimal CLI (always part of the project plan) to utilize free computing on the sender's machine to handle the encryption and decryption. Eventually we will need to shift to a dApp to handle this, but for the sake of this class, I'm going as minimal as I can.

You may have noticed I have 2 somewhat concurrent and circular issues to handle - building a CLI to handle the computing needed for encyption and an encryption algorithm to properly store the content. It sort of feels like a snake that's eating itself. Or, a better metaphor: chain that links to itself. What's the starting link? I've decided to move forward with the encryption first, in a solution I'm calling decx Encryption Key Service (dEKS), which will pass the encryptions generated back to the contract as it awaits to create the transaction in a batch, rather than having to recreate hashing algorithms off-chain or get the sender to sign off on every single hash created.

If you aren't following this, don't worry! I'm hanging on by the seat of my pants here and I'm supposed to be the guy with the plan. Hopefully next week's report will have a much clearer description of how this all works, due to me actually building the thing out and seeing how it works.

Last thing, I must mention that I got the encryption roughed out last week by throwing a dummy non-encryption encryption algorithm on the contract to prepare for integrating with a more substantial solution. As expected, fees were much higher due to the additional computing happening:

Before dummy encryption fees

┌─────────┬──────────────────────────────────────┬──────────────┬───────────┬───────────┐
│ (index) │              Operation               │  Gas price   │  Gas fee  │  In USD   │
├─────────┼──────────────────────────────────────┼──────────────┼───────────┼───────────┤
│    0    │  'novel hashing of "Hello, world!"'  │ '1519812028' │ '1038681' │ '$4.3171' │
│    1    │ 'hashing attempt of "Hello, world!"' │ '1459334849' │ '428272'  │ '$1.7092' │
└─────────┴──────────────────────────────────────┴──────────────┴───────────┴───────────┘

After dummy encryption fees

┌─────────┬──────────────────────────────────────┬──────────────┬───────────┬────────────┐
│ (index) │              Operation               │  Gas price   │  Gas fee  │   In USD   │
├─────────┼──────────────────────────────────────┼──────────────┼───────────┼────────────┤
│    0    │  'novel hashing of "Hello, world!"'  │ '1519812028' │ '4705166' │ '$19.0037' │
│    1    │ 'hashing attempt of "Hello, world!"' │ '1459334849' │ '428272'  │ '$1.7092'  │
└─────────┴──────────────────────────────────────┴──────────────┴───────────┴────────────┘

You can see the novel hashing of "Hello, world!" is almost 4.5 times as costly with the encryption, but once a novel hash is stored, reusing it costs pretty much exactly the same in both. My hope is that by moving the actual encryption onto the sender's machine and getting free computing with that, the fees go back down to what they originally were for the novel hashings. Let's see what actually happens next week!

Last Week

What I Said I'd Do

Iceboxed Priorities

  • Build out a method for retrieving the DecxDAG hash from the contract via an API endpoint and viewing the original string (2 weeks week ago)
  • Deploy the built contracts to a testnet (from 3 weeks ago)
  • Plan how the API will work, what endpoints and methods it will have, and which tools I should use to implement it (from 3 weeks ago)

Additional Accomplishments

  • Wrote out a few tickets:

    • Update dependencies [#32]
    • Emit a Novel Hashing score to denote the uniqueness of the string pressed [#28]
    • Research and Add license [#30]
    • Implement CLI for Pressing & Releasing Content [#35]

Next Week

Blockers

I'm in the rough of it now. There's no blockers but I'm seeing threats from all sides.

Reflections on Process

I'll just mention working with the team here.

Carlos has requested to work on a ticket pertaining to keeping track of the uniqueness of the pressed content due to how many novel hashes are created [#28] and Noah took on the task to update dependencies with critical or high vulnerabilities [#32] off the backlog without telling anyone and already got it up for PR [#33]. Even though things are feeling shakier in terms of next steps, the fact that I don't feel alone is helping me stay on task.