Skip to main content
search
Tag

smart contract

uchami
In Advanced, Blockchain, Blog, Ethereum, Solidity, Web3

Code Like a Pro: The Quick Path to Smart Contract Mastery

Code like a pro

This article was written by Boro and Uri, Mighty Block blockchain developers, You will find in it the path to becoming a Smart Contract Developer!

Stepping into the digital realm’s dynamic frontier, where innovation intertwines with decentralization, is the path of a smart contract developer. In a world shifting from Web 2.0 to Web 3.0, our role has gained unprecedented prominence.

Imagine writing code that represents unalterable agreements and cutting out intermediaries – that’s the magic of smart contracts. This article is your gateway to understanding what it takes to become a master of this blockchain-powered craft. From unraveling the intricacies of different programming languages to illuminating the deployment process on diverse blockchain platforms, we’ll embark on a journey that unveils the profound evolution from lines of code to immutable digital contracts.

What is a smart contract?

At its core, a smart contract is a decentralized digital agreement that runs on a blockchain. Imagine a traditional contract that outlines the terms and conditions of a transaction or agreement. And now envision this contract automated, enforced, and executed without needing intermediaries. This is where smart contracts shine.

Structurally, code composes a smart contract and defines the rules, logic, and conditions of an agreement. Think of it as executing a virtual ‘if-then’ statement: if certain pre-defined conditions meet, then the contract executes a specific set of actions. This structure ensures the transactions to be tamper-proof, transparent, and irreversible once executed on the blockchain.

Why web3

In the evolution of the internet, we’ve moved from the static websites of Web 1.0 to the interactive platforms of Web 2.0. The transition to Web 2.0 brought us social media, online collaboration, and user-generated content, all centralized on platforms owned by big tech companies.

However, the model came with drawbacks. User data privacy concerns and the centralized control of information became apparent as platforms monetized user data and exercised content moderation power.

This sets the stage for Web 3.0, a decentralized paradigm shift. Web 3.0 leverages blockchain technology to distribute control, data ownership, and transactions across a network of participants. This means that users own more of their data and identities, and execute transactions in a transparent and secure manner without intermediaries.

As data breaches, content censorship, and privacy issues continue to plague the digital landscape, the move towards Web 3.0 gains momentum. Its emphasis on user empowerment, privacy, and open protocols is driving innovation. With the potential to redefine how we interact online, from social networking to financial transactions.

Main smart contract structure

Let’s say we want to create an ERC20, the MightyBlockCoin that goes by the ticker MBC, our contract should keep track of MBC wallet balances, allow to transfer between wallets, amongst other functionalities. This is what the structure of such a contract would look like:

  • Constructor: This piece of code executes before the deployment finishes and typically sets some initial data on the storage of the contract. Since deployment is the only time this code runs, the system uses and tosses it, and does not actually store it on the chain.
    For MightyBlockCoin we want to limit wallets to a maximum of 10 MBC per transfer. Our constructor will set maxTransferAmount to 10.
  • Storage definition: These are your persisting variables, where you will keep useful information for the usage of the contract. You have the well-known integers, strings and bools and also complex data structures that go by “structs” on Solidity, but the most useful ones are mappings that basically work as non-iterable dictionaries with very fast access by key.
    Our ERC20 will need to keep track of balances, for such purpose there will be a mapping(address => uint256) this means a dictionary where the wallet addresses are the keys and their balances are the values, we also need to store the maxTransferAmount that we set on the constructor.
  • View methods: Allow the user to access a piece of information without modifying the storage-state and incur no gas cost, thereby not making all transactions equal.You can try to restrict access to view methods, but it’s generally a bad practice to do so and the barrier is easily avoidable by skilled inquirers.
    In our example, we would have a getBalance method where walletAddress is the parameter and we return the MBC balance of such wallet.

Next steps of a smart contract structure

  • Storage-modifying methods: Methods for security, access, consistency, and permission checks, which allow storage to mutate, form the backbone of a smart contract. When these checks pass, the system performs the storage altering actions.
    The transfer function for MBC validates that the sender has enough balance and the transfer amount is lower (or equal) than maxTransferAmount. Lastly it stores the new balances for both the sender and the receiver.
  • Events: Transactions on the blockchain do not provide any response other than the fact that it executed. We emit personalized events defined on the contract to keep some type of log of what happened. Events come with a name and parameters, they are the basic tool that most platforms use to keep track of what’s going on.
    For an MBC transfer we would want a Transfer event with parameters sender, receiver and transfer amount.

EVM vs NO EVM + testing

Venturing further into the realm of developing smart contracts, it’s crucial to grasp the landscape of blockchain ecosystems and programming languages that power them.

We can broadly categorize blockchain platforms into those that utilize the Ethereum Virtual Machine (EVM) and those that don’t. EVM-based blockchains, like Ethereum blockchain itself, offer a standardized execution environment for smart contracts, ensuring consistency across different nodes. On the other hand, non-EVM blockchains networks, such as Algorand and Solana, employ their own unique execution environments optimized for specific purposes.

smart-contract-developer

When it comes to programming languages for a smart contract developer, Solidity stands tall as the primary choice for Ethereum-based contracts. It is a statically-typed language specifically with a design for writing smart contracts. That is the importance of Solidity smart contract development.

Vyper is another language for Ethereum network that focuses on security and simplicity, making it a preferred option for scenarios where code clarity is paramount. Beyond Ethereum, Rust has gained attention for its use in the Solana blockchain due to its efficiency and safety features.

Testing and developing smart contracts

But programming languages are just one piece of the puzzle. Testing and development environments play a crucial role in ensuring the reliability of a simple smart contracts. Tools like Hardhat, a JavaScript-based development environment, and Brownie, its Python counterpart, provide testing, deployment and debugging capabilities.

They enable developers to simulate blockchain environments locally, helping to catch errors and security vulnerabilities before deployment. These tools offer sophisticated testing frameworks and integration with popular testing libraries, enabling developers to write comprehensive test suites to ensure contract functionality and security.

Navigating the landscape for smart contract developer involves understanding the nuances of EVM and non-EVM blockchains, choosing the right programming language for the job, and utilizing robust testing frameworks. As the ecosystem evolves, developers need to stay adaptable, continually learning and adapting their skills to keep up with the dynamic world of blockchain technology.

New challenges in web3

Testing

Our experience with testing Solidity has been quite challenging, for our particular use case and technology stack, we decided that Python + Brownie suited us best.

The reality of the matter is that Brownie emulates a real environment locally.This means that deploying smart contracts is necessary for sending transactions against them. Since you can only interact with the public/external methods, the ability to create unit tests is limited, as calling internal or private methods is not possible.

smart-contract-development

Deployment

Deploying smart contracts can be even more challenging than testing. Usually developers and owners are different people, this means that a developer might not have access to the private key, which in turn means that someone else, following the dev’s lead, has to send the transaction with the owner wallet.

Since smart contracts code are immutable by design, each deployment is a big deal. For that reason we work to ensure that the experience is secure, smooth and seamless as there are no rollbacks. In practical terms, for every deployment that we schedule, we plan ahead and create a checklist with the step by step guide of what to do, which commands to run and in what given order.

Security

The mix of the monetary value stored inside a contract and its immutability makes thinking about security crucial ahead of time, as rules cannot change on the fly. On top of that, every transaction is independent, there is no such thing as a session, it must check all possible scenarios every time to ensure that only the intended usage is the allowed usage.

Any open exploits serve as entry points for hackers and malicious actors, and even when detected, the issue remains unfixable since altering the contract is not possible.

Technical limitations of Solidity

There are no floating point numbers, this leads to using integers to store numbers with decimal places, making it sometimes confusing to know the number’s scale.

Another impractical limitation is Solidity’s inability to keep complex data structures in storage, requiring the developer to find a workaround to store the data in a more complex but Solidity-friendly way.

Thirdly, an arch enemy of the developer is Solidity’s impossibility to handle dynamic size arrays. For example, when searching all elements that meet certain condition, the data must be looped through once to determine the array’s size and then one extra time to populate said array with the matching elements.

Last in this list but definitely not least is the infamous “stack too deep” error, which appears when too many variables are being used in the context of one given function, forcing workarounds to remove variables or reorganize code into separate smaller functions until the error is gone.

Liveops

Once the contract has been deployed, all types of issues may arise, the blockchain scanner, blockchain query tools amongst other, are essential tools to master to be able to handle such scenarios. This usually entails following transactions around and reading logs/events until the root cause unravels.

Paradigm shifts

It’s quite common to encounter accesibility modifiers on functions such as public and private when working on a Web 2.0 project. In Solidity, 2 other visibilities must be taken into account including external and internal, security concerns of each option should be considered when using them.

The next big paradigm shift comes in the form of storage types. Storage is used in situations where memory isn’t best suited and viceversa, mastering the usage of storage types is essential as they are mandatory for most variable declarations. Finally, units are stored in different scales, most values might need some multiplication or division by 10**18 to account for the difference between wei and eth values.

External resources

Managing third party information requires workarounds as there are no APIs you can call or external resources you can access easily. Calling other contracts requires you to store their address and importing their interface in order to interact with them. The challenge of getting external information becomes substantial and oracles come to fill that void. Oracles are paid services that offer on-chain information that is not easily accesible otherwise, they represent to web3 what public APIs do for web2.

Language caveats

How would you sort an array of elements in Java? Well, you would simply call Array.sort(), that’s not an option in Solidity. Usually builtin methods entail a trade-off between performance and readability. Solidity is not willing to trade performance off, since performance is gas and gas is money. There are options like OpenZeppelin, which provides a library of frequently used methods to make the code more readable while still performing best practices. Nonetheless, implementing the methods for this basic operations still tends to be the best option. Other missing methods in Solidity are: min, max, filter, removeAt, foreach, etc.

Conclusions from a smart contract developer

As we conclude this epic journey through the realm of a smart contract developer, it’s evident that the digital landscape is undergoing a transformation unlike any other. The shift from Web 2.0 to Web 3.0 signifies a pivotal moment where decentralization, security, and user empowerment take center stage.

In the world of smart contracts, we’ve delved deep into their structure, the intricate web of challenges and opportunities that await the intrepid developer. Testing and deployment have proved to be crucibles where code is refined, ensuring the reliability of smart contracts. Security remains paramount, as every line of code written in the blockchain is etched in history, unalterable by design. Technical limitations and paradigm shifts have been embraced as challenges, not obstacles, by the developers pioneering this new era.

In this brave new world, we’ve witnessed the rise of oracles, the intricacies of storage types, and the relentless pursuit of performance. The absence of built-in methods has sparked creativity, making the Solidity developer a master of their craft.

Through it all, we’ve come to realize that Web 3.0 is not just a technological shift; it’s a philosophical one. It champions the ideals of decentralization, data sovereignty, and transparency. As the blockchain ecosystem continues to evolve, adaptability and continuous learning become the armor of the smart contract developer.

We are waiting for your talent like smart contract developer

So, fellow adventurers in the digital realm, take these learnings with you as you embark on your journey into the ever-expanding universe of smart contracts. From the humble lines of code to the immutable contracts etched in the blockchain, you are the architects of a decentralized future, where trust is forged in code and the magic of Web 3.0 becomes a reality.

As the digital frontier beckons, remember, you are the pioneers, the masters of blockchain’s arcane arts, and the guardians of a more equitable and decentralized digital world. The future awaits your code.

We are always looking for Web3 talent !

Mighty Block is one of the partners of Forte, a platform to enable game publishers to easily integrate blockchain technologies into their games. We believe blockchain will enable new economic and creative opportunities for gamers around the world and have assembled a team of proven veterans from across the industry (Kabam, Unity, GarageGames, ngmoco, Twitch, Disney), as well as a $100M developer fund & $725M funding, to help make it happen. That’s where you come into play.

Feel free to browse all our current open job opportunities in the following link 👇

View our open positions
Constanza Caballero
In Blockchain, Blog, Web3

5 aspects of UX in Web3 to improve

Mighty Block web3 ux

Since I started working with and learning about Web3, I became a curious user of any product I found. Therefore, now I want to talk to you about 5 aspects of ux in web3 to improve.

The lack of a good user experience struck me, and I found it similar to what Web2 went through before it became the Internet we know today. Web3 comes with really good technical advances and social foundations, such as decentralization, ownership and control of our own data. However, we can see how difficult it is for some users to navigate and understand these products.

Taking into account that Web3 still has a long way to go, it is essential to start this journey by mentioning some issues that UXers should pay special attention to.

What are the 5 aspects of UX that Web3 could improve?

1. Dev-centered content

The first UX aspect that web3 needs to improve is the technical acronyms and strings of alphanumeric information that are very common. This can be very difficult for a normal human being to read and understand. CeFi, DeFi, ERC-20, Smart Contracts, custodial, non-custodial and gas are some of the most popular terms. If you aren’t an expert user or a developer, these terms will most likely confuse and disorient you.

In this early stage, most product decisions are made by experts or developers, due they have spent more time working on it, defining and creating the technical foundations of Web3. But, the complexity this technology introduces appears hard to hide and presents many challenges to users.

We will need to add tooltips, explanatory text, guides or even a glossary with friendly information (see this glossary that helped me a lot on this journey). We need to know which technical jargon to use, when to provide the right information, and what our users truly understand. This knowledge will allow us to define content and communicate with confidence.

UX in Web3 - Transaction or message so it is easier to understand.

This is a reference of how you could improve a dApp transaction or message so it is easier to understand.

2. Asynchronous experience

Asynchronous experience is another UX aspect that web3 needs to improve. A single transaction requires multiple confirmations, as well as several pending messages to accept, and can occur on two different platforms (on your wallet and on the Defi App) within minutes of each other.

In most cases, the platforms do not provide all the information that the user needs to calculate, verify and accept the transaction. So the users must also check several sources or platforms simultaneously, such as the gas rate (fee), their token’s market performance (Token = any digital asset, cryptocurrency or NFT), the reliability of the address you are interacting with and so on. Also, most of this information is changing every few seconds. 

We can provide links to the correct sources while being clear that we are redirecting them to an external tool.

Also, we can provide the exact data they need in one place, as well as giving instant feedback to guide the user in this uncertain and asynchronous environment.

Users accustomed to Web 2.0 transactions find it unusual for a payment to be canceled or not realize it has been made. We must reduce the overwhelming feeling of Web3 transactions.

My last thought on this is about mobile usability, as these actions and queries happen across multiple apps, along with website changes, and the information we consult is usually complicated and full of data. It’s a big challenge to think in mobile-first solutions.

UX Aspects That Web3 - Interact with their wallet, but the dApp never told them to do it. 

How you could enhance that awkward moment where the users need to interact with their wallet. But the dApp never told them to do it. 

3. Response times for blockchain queries are slow

This is one of the aspects of UX that the design in Web3 most needs to improve. Web2 users know that a 3 second wait for a system response is a long time. So, we need to figure out how to handle waiting time on Web3.

We must consider that reading data already written and confirmed in the chain might be fast. But writing data could be very slow. So, if someone expects to complete a transaction and then read it immediately, that user will face disappointment.

Depending on several factors (and the chain, not all of them perform the same way), the time frame can be from seconds to minutes or hours.

When pushing a transaction to the blockchain, it does everything a traditional database does. However, carrying more operations, including verifying signatures and validating tx with a consensus method, slows it down and adds more time before processing a transaction.

We need to be creative on how the users perceive the time. We need to be really clear about their actions status (ie. started, processing, finished), counters and loadings are a good tool to explain whatever the system is doing and how long it could take. Keep them on track!

web3-ux-improvement

Here is an example of how you could enhance a dApp that needs to tell the user what is happening during a long or difficult transaction process.

4. New users mindsets are unknown

There is no doubt that Web3 brings with it major paradigm shifts, which will bring changes in the way users interact with it.

Decentralization will enhance the participation of the community in the development of this technology. Taking the ownership of our own information will make us more aware of how and where to use it. And force us to take full responsibility for keeping it safe.

Knowing that Web3 is still in its discovery phase, no one knows what they want or how they want it. The market price hasn’t even stabilized! It changes constantly at a pace hard to track, causing a feeling of chaos and stress. Will people adapt to this, or will this technology adapt to its new users mindsets?

To improve the UX aspect that Web3, It is necessary to keep our users close to us, to get to know them and to be aware of their needs and expectations, even if they don’t know it yet. Including user research, usability tests, metrics and other research methods that suit us, it will help us discover step-by-step the new mindsets and behaviors on which Web3 will be based.

There are plenty of active users who love to share information, whether openly or anonymously, on Twitter and Discord. There are even some Web3 projects for this; for example, there is a nice tool to obtain user insight, called Early Ones, that offers feedback and opinions from users that already are consuming Web3 apps in its early stages. We just need to look around, find our target participants and do our research.

5. Lack of education to the newbie web3 user

The last aspect of UX in Web3 needs to improve is the lack of education of the novice user. Newcomers can feel overwhelmed and disoriented when landing on a Web3 product for the first time. This happens especially on the first few screens of the product, which show all the information, features and options at once. There are no instructions and the system expects the user to figure out its usage independently.

The users must pay attention and be aware of all their interactions. There is no going back in blockchain matters, here is no customer support to solve the mistakes. If you don’t know what you’re doing, you could lose your tokens, keys, or other assets forever. And keep in mind that nothing on Web3 is for free.

Thus, a newbie faces a high barrier to entry and is prone to mistakes when it comes to niche knowledge. Is the UXer that should prevent any kind of undesirable mistakes where possible.

It is clear that the blockchain technology itself is a complex theory and challenges the user to be informed. But, it takes a lot of learning to fully understand it, and it shouldn’t be this hard for newbies. We need to educate, motivate and guide them. 

To engage new users smoothly and faster in this world, we need to devote resources and efforts to educate them and provide friendly and digestible information.

Detailed manuals are not necessary. But the use of FAQs, help docs and walkthroughs could be good options, as well as paying special attention to our onboarding flows.

Also, we can add goals for users to achieve as they progress from newbies to advanced users. Therefore, this learning process can be simplified and more gradual.

ux-in-web3-design

Here are some ideas on how to improve the education intention on some platforms. Usually, you see this empty dashboard when you first interact with dApps, but none of them actively guide, motivate, or educate the users. 

Conclusion

This has been just a glimpse of some of the aspects UX that web3 needs to change. But, I know there are a lot of other aspects that we could improve to make our new users’ lives much easier.

Good UX practices haven’t yet emerged and we have many challenges to overcome. The expectation and the high bar that Web2’s users left us, will turn these challenges into a real statement as something to motivate us to improve ourselves.

We are at a time when we need to use the best of web2’s design and mix it up with the best UX solutions that this new era will bring. Based, for sure, on new users.

We are always looking for Web3 talent !

Mighty Block is one of the partners of Forte, a platform to enable game publishers to easily integrate blockchain technologies into their games. We believe blockchain will enable new economic and creative opportunities for gamers around the world and have assembled a team of proven veterans from across the industry (Kabam, Unity, GarageGames, ngmoco, Twitch, Disney), as well as a $100M developer fund & $725M funding, to help make it happen. That’s where you come into play.

Feel free to browse all our current open job opportunities in the following link 👇

View our open positions
Close Menu