Taking the initial steps to building on a blockchain can be rather daunting if you don’t know the tips and tricks that will save you hours of development and research time. dfuse is talking to experienced blockchain developers in the community so as to pass this valuable information along. This week we spoke with Natanael Prudhomme from LiquidApps.

Could you introduce yourself?

Hello, my name is Natanael Prudhomme and my story is a little different than most. My journey actually started on a random Saturday where I sat down and plotted out what I thought were the biggest emerging technologies at the time: AI, VR, and blockchain. AI seemed too complicated with all the algorithms, I bought an Oculus and returned it after only 2 months of use, so I got interested in blockchain.

I didn’t do too much research until the Bitcoin peak in late 2017. Like many others, I road Bitcoin/Ethereum down through the coming months. Through that process I became interested in the technical side of the technology. January was my Bitcoin month. After diving deep into topics like Lightning Network and the rationale behind Bitcoin Cash and block sizes, I decided Bitcoin was not in a position to scale, so I turned to Ethereum in February. Ethereum was more interesting with the idea of smart contracts, but still suffered from the inherent scaling issues with being a Proof Of Work chain. I wasn’t sold on their theoretical scaling solutions, so I kept looking until I found EOS in March. I went down the typical rabbit hole: Bitshares, Steemit, and now EOS. I believe in Dan Larimer, his approach, and the experience of his core team, so I bought in fully by quitting my job to dedicate myself to becoming a blockchain developer.

This was a bold move at the time from most perspectives given that I got my degree in management and had basically zero dev experience beforehand, but I was determined. Over the next 6 months, I took over 100 hours of developer courses on Udemy including C++, Node, React, Mongo, and CSS so that I could build my own dapps. I wound up building 3 dapps in that process. I also built my way up to being the second highest reputed member of the EOSIO stack exchange.

I interviewed with multiple companies as well, Block.one being one of them, getting shot down each time due to my lack of “experience”. Then after getting rejected from being a mentor at the first hackathons, they had an opening due to a lack of mentors for the San Francisco hackathon, so I got an invite. I met Tal Muskal, the CTO of LiquidApps, randomly at the mentor dinner. Well aware of the current bottlenecks of EOS, he told me of the vision for LiquidApps and we wound up talking about the subject the whole night.

After the hackathon, I stayed in touch with Tal as I was taking a few side dev jobs trying to build up my experience, but they were not going anywhere. He needed a front-end dev that had some blockchain experience to build the LiquidApps site, so I got on a call with Beni (Hakak, CEO of LiquidApps) on Christmas day where he said he would give me an opportunity to prove myself.

Over the next 2 months, I worked hard to make sure the site was perfect. By the end, I got an official offer to become a member of the team. My hard work had finally paid off.

Could you describe the projects you’ve worked on?

In my early days I built 3 dapps. The first was ChessEOS, Syed (Jafri, CEO of EOS Cafe Block) still makes fun of me for this project. It was a simple chess game that used EOSIO to send chess moves on chain. To me, it was like my first child. Then I forked a WebSocket-based chat room application and added dfuse / blockchain to it so I could see the transaction status move from “sent” to “accepted” to “irreversible”. My last project was an app based on bringing awareness to the need to have different owner/active key pairs, so you could plug in a username and the UI would alert you if your keys were the same.

Now I’m working at LiquidApps. Our flagship product is vRAM, a RAM scaling solution for EOSIO. RAM is a big bottleneck for development teams and not everyone has the funds like Block.one does to be able to purchase enough RAM for their initial users. To help with this, Tal created a caching solution powered by DSPs (DAPP Service Providers) to allow data to be loaded into RAM when it’s needed, then evicted from RAM after it’s needed. Effectively transitioning the RAM footprint for a smart contract from all data for all its users, to only the data for active users needed during the lifecycle of their transactions. This is effectively minimizing the total RAM needed by a significant amount.

We also have solutions in the pipeline for things like oracles, randomness, vRAM based EOS accounts, and vCPU, a CPU scaling solution.

What are the main challenges when developing on a blockchain?

The biggest challenge for me was learning C++ from not having a development background. I learned this as my first language and said some nasty things to my computer in the process. Other than that, I didn’t really run into many issues that couldn’t be solved by popping into the dev channel or posting on the stack exchange.

The other issue when developing on blockchain is the user experience. It sucks right now if you’re not tech savvy or have previous experience with blockchains. But with technology like LiquidAccounts, anyone and their grandmother can use blockchain without knowing it.

Can you describe your experience as a developer in the EOSIO ecosystem?

Getting an invitation to mentor the SF EOS Hackathon is a memory I will never forget. It was so cool meeting other developers and people interested in blockchain. The word “EOS” has become a blacklisted topic with family and friends, so having the ability to geek out with other people as passionate as me was truly something special.

Seeing Tal in action as a mentor was really cool too. There was one issue I remember where Peter Keay’s team had an issue and since Block.one had just updated EOSIO breaking a bunch of stuff, no one really knew what was going on. We were 4 mentors deep without a clue. Then Tal walked over and figured out what was wrong in a few minutes. He smiled while he was explaining how he “cheated” because he had read the source code already, so he knew what had changed.

You recently moved to Puerto Rico, what is the crypto scene like there, and what should other developers know about it?

Puerto Rico is awesome! We’ve been having a few political issues, but aside from that, it’s a great place to be if you’re in the crypto space. Moving to Puerto Rico made a lot of sense for me financially. If you haven’t looked into moving there and you’re in the US, I would suggest you consider learning about the advantages. It could make a lot of sense for you financially. Find me on Telegram if you have any questions. The crypto scene down here is amazing, the weather is awesome, and the people are great. There are a lot of all stars in the EOS space that are down here as well such as Brock Pierce, Luke Stokes, Colin Talks Crypto, Zane of EOS Radio and more.

What advice would you give to a developer who wants to build a project on blockchain?

If you’re a new dev coming into the space, you should definitely check out Peter Keay’s eosio developer course on Udemy, that’ll get you through the basics. The developer channel and the stack exchange are also really good resources. My main tools that I use are Scatter (wallet), bloks.io (block explorer), dfuse (api service for blockchain info), and Zeus. Zeus is a tool LiquidApps built and it’s super cool because with 4 commands you can download everything you need to start a local testnet (including eosio and the eosio.cdt), get test accounts up, stake resources to those accounts, compile a smart contract, and run some unit tests, all with no cleos! If you’re from the Ethereum space, it is similar to Truffle.


If you think that you have some great insight to share and would like to be featured on “In the Eyes of a Blockchain Developer”, please feel free to reach out to us! We would love to share your story and help inspire the many developers who join the blockchain space each and every day.