Cover photo

EIF Diary — Week 5+6

Moving the ship forward, here’s the time line for my 5th and 6th week at EthIndia Fellowship.

Week 5 was basically just a defi speed run for all of us, each of had been assigned a defi protocol to research about and then present, it was quite fun, all of us learned a lot.

  • I had to research about tornado cash

  • Spilling some of what I learned here, tornado cash to sum it up is an open source, non custodial crypto tumbler — a tumbler is a service that mixes potentially identifiable crypto funds so that you cannot trail back to the fund’s original source. this is usually done by pooling together source funds from multiple inputs for a large and random period of time, and then spitting them back out to destination addresses.

  • Want to learn more about the whole tornado cash story and its crash? here’s my entire presentation!

     

https://www.figma.com/proto/jWfXoswnMfjcbkaSNjMaru/tornado-cash?page-id=0%3A1&node-id=1-2&viewport=-3958%2C530%2C0.3&scaling=contain&starting-point-node-id=1%3A2

Moving ahead, week 6 begins and so does the build phase, so, what am I building?

  • Introducing tinyhack — smart contracts which are to be deployed for real-world use-cases, by real people, need to be secure. the crypto lost owing to poor security is in the millions & to set the standard for a secure smart contract, it must follow basic but key checks. enters tinyhack, a tool which can tell you on-the-fly where you're leaving room for adversaries to enter, what attacks your contract will be prone to, if deployed.

  • what are we proposing?

    • a dev tool which takes your evm smart-contracts written in solidity and runs it through various layers of security checks, simulating many kinds of syntactical, semantical vulnerabilities, gas optimizations and attacks [hacks] which have happened previously on evm smart-contracts — returning a simulated audit of security weaknesses while also flagging the lines which could make the contract prone to attacks and offering potential optimized solutions.

    • there are many pre-security checklists, vulnerability test cases, and static contract analysis out there and what we wish to do is — bundle them all in together, automate the process and wrap it under an impressive ux so that any programmer can start using it right away and deploy better and more safer contracts.

    • who is this for? regular programmers working with smart contracts for learning purposes, a tool for them to use to improve upon their existing coding conventions & styles without having to pay to put their product’s code through an enterprise-level audit. this sets a higher standard for contract code amongst the web3 community, and sets the security rigor stronger for smart contract development

  • why this?

    • urge to improve web3 security ux by reducing friction without having to download tons of tools and figuring out their abstract responses.

    • there isn’t any similar product in the market, the ones present are cli-only each being good in their own way but individually, not enough alone, leaving certain vulnerabilities which could become issues in future, there would be barely anyone going their way to run checks through multiple tools simply because of the hassle it creates and the abstract responses that come with each tool.

so without waiting for anything further we got into building but things didn’t go as planned

  • after spending the whole week trying to build this we concluded that the tools we want to build this on top of, static and dynamic analysis tools, have a design flaw in them. they are good to go as individual tools but when you try to use them through a third tool or python or node or just stack them up, they crash, they tools are not yet designed to be used for the purpose we originally had planned about and none of us saw this coming.

so what now? we pivoted! stay tuned next week to see what did we change to :D