Skills and career of a Solidity developer, cross-chain swaps, and ZKP
"If you've come up with some use case with ZKP, you need to start a startup because it's hype"
Sonya Sun
June 29
"If you've come up with some use case with ZKP, you need to start a startup because it's hype"
About the Background and Starting a Developer Career
I studied at HSE in the Faculty of Computer Science but only completed 3 courses. I studied during the crypto and blockchain hype. Then I was offered a job, and I thought it would be better to focus on that rather than studying. Before working, I had already completed two internships - at Google and Yandex, during the 3rd course. I also made it to the semifinals of ACM ICPC NEERC for the Northwest region twice. This helped me get into Google and better understand what I'm doing now.
My first job in crypto was at LATOKEN, then Harmony, where I engineered the protocol, followed by THORChain.
After that, I moved to DeFi. I was CTO at the Prosper project, which we later sold with the guys. For some time, I went to Windranger Labs as a developer in the department that was developing DeFi tools, such as Governance Framework, and collaborating with other projects.
I have worked in all areas of web3 and everything related to decentralization and distributed systems. Developed blockchain, PoW and PoS, staking functionality, tested various solutions.
After Prosper, I also worked at BitDAO - worked on projects related to NFT, wrote backends and smart contracts for auctions. But DeFi is much more interesting in development because NFT projects are more about marketing. Because purchases and sales themselves do not work through regular market maker orders.
About the Offer from 1inch and Its Product Features
I was offered a position as a Solidity developer. I thought it was a pretty good option overall. The procedure was standard, with an interview. 1inch has a very competent and solid team. I have been working with them for half a year and still continue to learn a lot from them.
1inch initially aggregates all orders by price. Accordingly, the orders we choose have the least arbitrage. But, of course, you can find a pool with the lowest trade price from arbitrage and sell it more expensive.
1inch works with different auditors. I personally had experience working with Certik and Least Authority. The most expensive and difficult to access auditors are at OpenZeppelin. But they are the coolest there.
Now 1inch is a very important product in DeFi. And despite the fact that it is difficult to get to OpenZeppelin even for money, they work with 1inch. There is also MixBytes - it's cheaper, but the auditors there are also good. 1inch worked with them too.
About Bridge Problems and Their Differences in Operating Mechanisms
In general, there is a problem with secure bridges in the industry now. When you want to transfer a token from one chain to another, you have to keep them in some contract. If the chain is intricate or centralized - the risk of hacking is high. Unlike the blockchain, where the structure is very rigid in terms of tokenomics, cryptography, and consensus, - a bridge, as a rule, has broken protection mechanisms between chains.
But there are also quite robust bridges. But they are complicated. For example, Rainbow Bridge. They tried to break it, but all attempts were unsuccessful. This is how the mechanism is arranged - with a transfer between bridges. You cannot quickly transfer money, for example, between Ethereum and Near, so that they are 100% confirmed by you, and transfers can be challenged.
There are several validators that collect state from Near or Ethereum and send it to the corresponding chains. That is, from Ethereum to Ethereum and then to Near: so that you have a contract in which the state of the opposite chain is published.
This is published so that a person who really deposited in the bridge contract on the corresponding chain can generate proof of this deposit for himself and, using this proof, come to another chain. Then this proof is compared with another state in the chain or contract that was launched. According to the same formula, for example, a block has a Merkle Root, by which you can check whether there was a transaction in a particular block. Accordingly, it is possible to check that the general state of these transfer deposits in the bridge is correct.
There is such a dependency: validators who push the state from the blockchain can be bad, but if there are 20 of them, there is a high probability that it will be more decentralized and correct - because they will agree. Near and Rainbow Bridge bridges work quite close to decentralization.
There are a lot of bridges in general, and there are different types. Clayton Bridge, for example. There are separate ones - at Avalanche and Binance. Also, all bridges work differently. Some are super centralized, and some, again, like Rainbow Bridge, are close to decentralization. L2 blockchains, for example, Arbitrum, Optimism, or zkSync bridges are sharpened according to a specific principle - they are all rigidly built specifically for L2 solutions.
About the Challenges of Junior Developers Getting Hired and Their Differences from Seniors
When startups hire developers, juniors often get overlooked. It's quite rare for management to decide to hire a junior for a developer position. They typically want experienced individuals ready to deliver results.
With CTF experience, you can try for junior and middle positions. Don't be afraid to send out numerous applications if you're genuinely keen on landing a job. Seize any opportunity. Even if the position is low-paying, you'll gain experience, making it easier to scale up. In any case, it's better than sitting and hammering theory. Moreover, you'll be able to receive feedback and, consequently, understand what's working and what's not.
Experience is the simplest and most crucial thing to have. Understanding code and architecture, and the ability to solve specific tasks, comes with experience. For instance, a database. It can be decentralized, have more or fewer replications. Understanding the practice of these trade-offs is vital. It's challenging to comprehend something without experience.
Yes, ChatGPT might assist you — but in a fluid manner. Everything is learned through practice: write a database or server once, and you'll start understanding how it works.
Since seniors have more practice, they will complete these tasks faster and better. That's all.
Different requirements apply to them — they should be able to create optimal architecture and explain the product's operation to the manager, develop and implement component architecture, and also deliver it on time.
There may be pitfalls, for example, security details — especially common in Solidity. And all of this is learned through practice. This doesn’t mean that a junior can’t handle such tasks. Simply, they don’t have the hands-on experience with contracts, specific security moments, meaning the developer will handle it less efficiently, and possibly, might not understand the difference between one solution and another.
About the Necessary Knowledge Base for Upgrading a Developer's Grade
It's crucial for developers to understand cryptography — it's foundational. The same goes for Zero-Knowledge — as it is in zkSync and ZK-proofs. ZK is used to a lesser extent at the DEX level, but it's still better to understand it.
This knowledge is not so widespread in the industry; after all, these are complex algorithms — some of the most complex ones currently available in crypto. In principle, Merkle proof is also a ZK-proof. Only ZK needs to be adapted for different cases. There are many different ways ZK technology can be implemented.
But there’s still no practice — it’s hard to come up with a non-obvious use case with ZK, other than just a scalable chain. Yes, there can be mechanisms that allow you to compose swaps into one transaction, but again, what will be the composition and why do it in your protocol if zkSync already exists.
If you've come up with a use case with ZKP, you need to start a startup because it's hype.
About Mandatory Languages for Solidity Developers
I think all Solidity developers should write in JS, specifically TypeScript. I would say that there is a difference in language features between JS and Solidity. Although fundamentally everything is the same. TypeScript is standard. You need to know it to write tests. There is a Foundry framework that allows you to write tests exclusively in Solidity. 1inch uses it in some cases. And now the question is whether we will fully transition to it.
Of course, if you want to be a senior, you need to understand how contracts will work from the frontend and backend. There's an application you need to work with and understand what will work efficiently.
If you want to dig deeper into Ethereum development, there is Vyper. It is becoming increasingly popular. But Solidity still remains the primary language on Ethereum.
Knowing Python is also useful because Vyper is very close to Python in style, syntax, and features.
I had experience interviewing Solidity developers when I worked with Prosper. But we didn't need a deeply immersed developer. Nevertheless, I looked at blockchain knowledge. Often in interviews, they ask not only about Solidity but also how blockchains work.
It's better to start getting acquainted with blockchains in terms of development from the base — PoW, PoS, understanding the difference between them, how EVM works. This base will also help understand all the changes happening with Solidity. It's also better to understand the internal details of Ethereum itself. For example, MEV. The basics of Computer Science algorithms and optimization are also useful.
About the Algorithm of Cross-Chain Swaps and the Special Mechanism of THORChain
Initially, cross-chains are based on atomic swaps, even before the existence of Ethereum. This technique is based on cryptography, following the principle of generating secrets on both sides. Parties exchange locked transactions using these secrets, and then, when the time comes, the funds can be unlocked. On Ethereum, you can swap through smart contracts, which support any logic.
THORChain is a fascinating project. Its trading structure technique is similar to Uniswap — with a liquidity curve. There are internal pools tied to THORChain's native currency, RUNE. The pools vary: BTC/RUNE, ETH/RUNE, etc.
For somewhat accurate work with BTC and ETH, THORChain has developed a special mechanism. It operates based on threshold signatures — and it's not about multisig. It's Threshold ECDSA. The difference is that multisig, unlike Threshold ECDSA, generates signatures asynchronously. It turns out that each person, who is part of the multisig key, adds their signature, and it grows in size.
For RUNE, signatures work the opposite way: participants must gather together and generate a signature. THORChain is simpler in creating all wallets for ETH and BTC, which will be managed by network validators. Thus, you can have more people responsible for these keys and wallets. They can stake RUNE in the same pools. And if they take your money, they can be penalized. This is much better than if you hire money on one Binance, for example. It's a more distributed system.
About the Role of ZK in Crypto and the Future of web3
ZkSync and zkSync 2.0 should be breakthroughs because, at the very least, users may not wait for their money after investing it in L2. The consensus in zkSync is not even about transactions but about the date that will go into the transaction.And what about rollups — you have proofs that the transaction execution was correct. You only need to check the date and state, that it was also correct. This is also a consensus. But the next step is to make this procedure trustless. ZkSync is definitely worth watching.
Also, keep an eye on any chains, for example, Polkadot and Near. There are quite robust and hyped products there. And they are more quality in practice. It is also worth watching the release of new protocols and DEXs in DeFi. In addition to zkSync, there is also the Aztec Network — a more compliance version of Tornado Cash. Only it's a separate chain that allows adding a privacy layer. It's very promising. Starware is also promising. They claim to separately publish ZK technology that allows validating and proving those very ZK-proofs from a million transactions. They claim they have some incredibly large scaling.
Now in web3, more interesting and technologically advanced L2-chains are appearing. Cooler than Harmony and Avalanche.
Honestly, I do not see fundamental reasons why the market should grow now. The memory of last year's scandals has not yet been washed away, and when it is, people will already start actively entering crypto and the markets.
I believe that the future is for zkEVM. There is even a separate startup that deals with a virtual machine on ZK — if you think about what opportunities this can give, it becomes very interesting. In theory, any distributed computing will be able to work on ZK. But so far, these are all speculations.
Bitcoin still has a large volume in terms of capitalization and blockchain use. But, in my opinion, there will be no explosion of Ordinals. It's hard to program NFTs in Bitcoin. And there is no such trustless system there. And Ethereum has a lot of options. NFT is about convenience and fun, and it's harder to implement in Bitcoin and the quality will be worse.
Bootcamp: Solidity Developer
From the basics of Solidity to deployment on the mainnet.
Share
You might also like
Application submitted
We will get in touch with you soon
Interested in diving into crypto?
We're here to help!
or
Or connect directly