Following our Smart Contract Auditing: Human vs. Machine article, we now analyze Slither, which is another static analysis tool from Trail of Bits. It includes aids for contract summaries, which can be helpful for making a mental model of the contract and rechecking assumptions. Considering the ease of use, it’s a good idea to try […]
In this article we are benchmarking several auditing tools. The smart contract security audit is a critical phase in the development of smart contracts. The DAO hack was just one trip in the odyssey to secure Ethereum smart contracts and compatible blockchains like RSK and Cardano. It is important to highlight that back in 2016 […]
In my last article, I’ve shown you how to make a Solidity ERC20 Token for the RSK Mainnet, how to import and use OpenZeppelin libraries and contracts, and how to use Truffle to deploy and interact with our contract.
Although we succeeded in our quest and accomplished our objectives using Truffle, eventually this suite might present failures when you are sending transactions, deploying or managing accounts. In our case, while following the previous article instructions, I’ve had problems managing newly created accounts in Truffle and sending transactions.
In the last article, we have seen how to build an RSK node in our computer, select the proper network for development, configure Truffle to connect and deploy our future contracts, add accounts to our node and obtain funds to use them to pay the gas.
You should have now your node in the selected network fully synced, and at least one account with funds configured in the truffle and RSK node config files for our deployments.
In this article, we’ll be discussing deployment and interaction of Smart-Contracts over the RSK network. Our contract will be an ERC20 Token, based on the OpenZeppelin libraries, and we will deploy it directly into the Mainnet.
These last years there has been growth in Smart Contracts development, predominantly in the Ethereum blockchain. Ethereum, being a different type of blockchain than Bitcoin, can execute concise lines of code inside its chain, a job that Bitcoin (specifically designed to send transactions easily) can’t do. Here is where RSK intervenes building a sidechain tied up to Bitcoin through a 2-Way Peg system, managed by the Federation Partners, that makes code execution possible. Instead of designing a new programming language for developing Smart-Contracts, they used Solidity, the same language that Ethereum uses. This has two benefits: not only programmers won’t have to learn a new skill but also contracts in the Ethereum network could be deployed in RSK without much effort, taking advantage of the vast market capitalization Bitcoin has.
Solidity semantics are confusing for smart contract developers with experience in traditional programming languages. This semantics can lead to security issues like the one we found in a recent smart contract security audit we did. The following code caught our attention: In the above code, the create method stores the same information in two different […]
Working for our customers in our blockchain development company we built this spreadsheet which is a work in progress, comments are welcome here, which describes the features of multiple blockchain and sidechain technologies. Views about blockchain technologies range from hype to skepticism. A blockchain is a distributed database and consensus network that can be used to […]