BLUE PAPER + AUDIT REVIEWED BY BAUTHERAI JAMES ON 7TH OF MARCH, 2022
I Hello, My name is Bautherai James, a ChallengeDac app user and a community member of challengeDac application. My username on the ChallengeDac application is @Bautherai
The following article is to stated a review on Eos audit in addition with Blue paper (audit + Blue Paper). This article will purposely based on analysis of security tooling contract audit for EOSIO-based applications.
𝑻𝒉𝒆 𝒄𝒐𝒏𝒕𝒆𝒏𝒕𝒔 𝒊𝒏𝒄𝒍𝒖𝒅𝒆𝒔
1. 𝑪𝒖𝒓𝒓𝒆𝒏𝒕 𝒔𝒐𝒍𝒖𝒕𝒊𝒐𝒏𝒔 𝒕𝒉𝒂𝒕 𝒆𝒙𝒊𝒔𝒕 𝒊𝒏 𝒕𝒉𝒆 𝒄𝒐𝒎𝒎𝒖𝒏𝒊𝒕𝒚
2. 𝑺𝒐𝒍𝒖𝒕𝒊𝒐𝒏𝒔 𝒕𝒉𝒂𝒕 𝒂𝒓𝒆 𝒅𝒆𝒎𝒂𝒏𝒅𝒆𝒅 𝒃𝒚 𝒄𝒐𝒎𝒎𝒖𝒏𝒊𝒕𝒚
3. 𝑬𝒒𝒖𝒊𝒗𝒂𝒍𝒆𝒏𝒕 𝒘𝒐𝒓𝒌 𝒅𝒐𝒏𝒆 𝒊𝒏 𝒐𝒕𝒉𝒆𝒓 𝒆𝒄𝒐𝒔𝒚𝒔𝒕𝒆𝒎𝒔
4. 𝑨 𝒍𝒊𝒔𝒕 𝒐𝒇 𝒊𝒏𝒊𝒕𝒊𝒂𝒕𝒊𝒗𝒆𝒔 𝒕𝒉𝒂𝒕 𝒄𝒐𝒖𝒍𝒅 𝒊𝒎𝒑𝒓𝒐𝒗𝒆 𝒕𝒉𝒆 𝑬𝑶𝑺 𝒆𝒄𝒐𝒔𝒚𝒔𝒕𝒆𝒎.
5. 𝑨 𝒍𝒊𝒔𝒕 𝒐𝒇 𝒓𝒆𝒄𝒐𝒎𝒎𝒆𝒏𝒅𝒂𝒕𝒊𝒐𝒏𝒔 𝒕𝒐 𝒕𝒉𝒆 𝒇𝒐𝒖𝒏𝒅𝒂𝒕𝒊𝒐𝒏 𝒐𝒏 𝒕𝒉𝒆 𝒃𝒆𝒔𝒕 𝒄𝒐𝒖𝒓𝒔𝒆 𝒐𝒇 𝒂𝒄𝒕𝒊𝒐𝒏.
The paper is provided with research and initiatives around improving the overall security of EOSIO blockchains. The research shows that very few solutions exist in the EOSIO geared towards security. The EOSIO core system is beautifully designed to allow for a security oriented approach, but there is much work required to bring it up to the same standard of security that other blockchains offer.
A key area that resides in this paper is knowledge. The self perpetuating knowledge with¬in developer communities which can only be achieved by giving them the right tools and documentation.
The huge security knowledge of the hacker communities and their inquisitive nature that we should harness to continuously secure EOSIO. The knowledge of our user base knowing that their interactions with EOSIO dApps are safe and secure, which is possible to achieve due to EOSIO’s unique structure as long as we provide the underlying services and APIs. As mentioned, the overall core design of EOSIO allows for a security oriented approach, we just need to focus on the basics and then go a step further, by harnessing some key EOSIO elements that will help us stand out from other blockchains.
To start with, the current solutions that exist in the community. Although there are some solutions available in the EOSIO community, but despite that there need to observe if there’s lack of foundational security oriented solutions.
1. 𝑺𝑶𝑴𝑬 𝑺𝑷𝑬𝑪𝑰𝑭𝑰𝑪 𝑺𝑶𝑳𝑼𝑻𝑰𝑶𝑵𝑺 𝑻𝑯𝑨𝑻 𝑨𝑹𝑬 𝑨𝑽𝑨𝑰𝑳𝑨𝑩𝑳𝑬 𝑨𝑵𝑫 𝑰𝑵 𝑨𝑪𝑻𝑰𝑽𝑬 𝑼𝑺𝑬 𝑨𝑹𝑬 𝑨𝑺 𝑭𝑶𝑳𝑳𝑶𝑾𝑺
a. Klevoya Inspect
Klevoya inspect is a tool that allows developers to upload their compiled WASM code and have it inspected for vulnerabilities based on unique patterns created by the Klevoya team. Inspect employs a technique called Static analysis. Static analysis is performed by reasoning about a computer program’s source-code, or some intermediate representation, without actu¬ally executing it. Under the hood, the uploaded WASM code and ABIs are uploaded into a proprietary interme¬diate representation that is loaded into a database. The patterns matcher is then run against the entities in the database looking for known vulnerabilities. The product is not open source and is a paid for service.
Features which includes, Automated scanning of uploaded compiled WASM code and Scanning engine that detects vulnerabilities in WASM code based on in house designed patterns
Benefits to EOSIO includes, the use static analysis fuzzing is a very powerful tool and will give developers a unique opportunity to self diagnose and self resolve security issues, which ultimately over time will make them better at writing smart contracts that are more secure.
b. Software development libraries.
EOSIO provides an eosio. contracts warehouse, which contains bios, system, msig, wrap and token contracts. Using the MIT License agreement, developers can use the code almost un-limitedly, and they can also master the EOS mainnet by learning these contracts including the governance parameters and economic models.
There are also some general use SDKs available in the community:
i. SX organization that has open sourced 9 DeFi-type smart contracts on Github, that con¬tain good quality coding standards and some of them have passed the security audit, but it should be noted that these libraries do not indicate the copyright agreement to be followed.
ii. Blockmatic, collected 112 community open source EOS smart contracts source code and made the list public. The code contains game, DeFi, payment, DAO, stablecoins, and NFTs , ICO and other types of contract examples and even projects that utilise Rust as a devel¬opment language, which allows us to see the developer’s enthusiasm for development on EOS.
Part of its feature is that, the community has a large list of open source coding examples, but the code that has undergone security audits is relatively small, and the amount is much smaller than that of Ethereum by several orders of magnitude. Most striking is that most of the code bases have been suspended for maintenance. It also have many benefits, for instance By developing and sharing a high-quality open source code base, the difficulty of development can be reduced, and developers with inexperience can quickly develop secure smart contracts, thereby increasing the adoption of EOS.
2. 𝑺𝑶𝑳𝑼𝑻𝑰𝑶𝑵𝑺 𝑻𝑯𝑨𝑻 𝑨𝑹𝑬 𝑫𝑬𝑴𝑨𝑵𝑫𝑬𝑫 𝑩𝒀 𝑪𝑶𝑴𝑴𝑼𝑵𝑰𝑻𝒀
Based on high level of research and speaking to stakeholders within the EOSIO community, below are key points would help improve the overall security of the EOSIO ecosystem.
a. Software libraries for secure smart contract development
Security hardened software development libraries (SDK) allow software developers to har¬ness battle tested contract templates and libraries to minimize risks when developing smart contracts. They are just like your standard SDKs, but included within them are pre-built examples of per-forming certain actions that are built based on best security practices, so instead of having to create your function that performs a certain action you can utilise existing ones that you know have been tested for security issues.
This is because, using such libraries will not only help minimize risk when creating smart contracts, as they help developers use existing methods that have already been scrutinized from a security point of view, but also allow you to include security testing within your unit testing.
Basic demands, EOSIO software developers want to create more secure smart contracts but we lack the overall tooling.
b. Bug Bounties
Bug bounties are monetary rewards given to ethical hackers who successfully discover a vulnerability in an application or piece of software. Widely adapted across all chains it plays a very important part in ensuring your blockchain code is constantly scrutinized, especially if your code base constantly changes or has multiple flavors.
This is because, having a well run bug bounty programme will attract the best of the hacker community to improve the overall security of EOSIO. The lack of such a programme is discouraging the hacker community from investing time and effort to look into the EOSIO code base.
c. Contract upgrade authorization DAO
EOSIO smart contracts are deployed to an active account and usually developers have full access to upgrade those smart contracts in the future. This creates a trust issue, because the users of that smart contract inherently need to trust the owner of the account that he will do no evil, regardless of the security audit status of the smart contract.
This is because, is previously mentioned we need a better way of managing contract authority to facilitate more trust between users and smart contract owners, whilst also allowing smart contact owners the ability to make updates to their software.
3. 𝑬𝑸𝑼𝑰𝑽𝑨𝑳𝑬𝑵𝑻 𝑾𝑶𝑹𝑲 𝑫𝑶𝑵𝑬 𝑰𝑵 𝑶𝑻𝑯𝑬𝑹 𝑬𝑪𝑶𝑺𝒀𝑺𝑻𝑬𝑴𝑺
Researching other blockchains a list of security related content and products that are generally always available on top blockchain protocols have been provided, the overall general theme of how security is approached is very similar across all blockchains. It as well covers a fairly new idea that has started to take fruition on Ethereum, which we also cover as one of our core initiatives later in the document.
a. Security Registry for dApps
It was found that in Ethereum a github REPO exists that is trying to list all the current smart con-tracts, given their chain, address and the associated project they belong to. It seems like a fairly new endeavour by ETH as looking at the REPO history it was started on Sep 2021. “The goal is to be able to provide information about an address when a user is interacting with it, as well as tracking security contact information for known projects in the event that a vulnerability is found in a given contract address.”
The list of ETH EVM chains currently supported includes:
3.Binance Smart Chain
b. Open source Security tools
Open source security tools are a very easy way for developers to self-assess the overall security of their smart contracts. Although not very common these tools do exist and they especially exist within the top tier protocols, we are actively trying to compete with. These tools promote self diagnosis and develop the knowledge of the developer community around common security pitfalls to avoid. ¹
c. Software libraries for secure smart contract development
These software development libraries focused around security are used to guide the development of smart contracts, reduce the difficulty of development, and improve code quality and security. They are just like your standard SDK but come with added features that help guide developers in writing code that is more secure.
These secure development libraries have excellent code quality, which is specifically manifested in:
i. Each type of application has a complete function realization;
ii. Simple and modular code;
iii. Function and variable naming methods with clear meaning and consistent style;
iv. Variable and function function annotation description;
v. Comprehensive unit testing;
vi. Support general package management tools, such as npm, cargo;
vii. After a more comprehensive security audit;
d. Common security pitfalls when writing smart contracts
Common security pitfalls are in-depth and up-to-date documents that list the past security mistakes made by developers in a particular blockchain. These documents are created to help future developers from repeating the same mistakes. Think of them as a list of rules to follow. Follow these basic rules and your smart contract will generally be secure from hackers,
Its features includes, list of common security pitfalls which include a description of the type of attack, some example source code showing where the mistakes occur, what vulnerabilities these mistakes could lead to and preventative techniques to allow developers to not repeat the same mistakes in their own code.
4. 𝑨 𝑳𝑰𝑺𝑻 𝑶𝑭 𝑰𝑵𝑰𝑻𝑰𝑨𝑻𝑰𝑽𝑬𝑺 𝑻𝑯𝑨𝑻 𝑪𝑶𝑼𝑳𝑫 𝑰𝑴𝑷𝑹𝑶𝑽𝑬 𝑻𝑯𝑬 𝑬𝑶𝑺 𝑬𝑪𝑶𝑺𝒀𝑺𝑻𝑬𝑴
Based on all the current solutions that exist in the community, what’s demanded by the com-munity and what we see that exist in other blockchain protocols we have come up with a list of initiatives that will help EOSIO get ahead in terms of security. There is some work required to get us to the same level as other blockchains, but once the EOSIO baseline is established EOSIO’s unique design will allow us to move a step above other blockchains.
5. 𝑹𝑬𝑪𝑶𝑴𝑴𝑬𝑵𝑫𝑨𝑻𝑰𝑶𝑵 𝑻𝑶 𝑻𝑯𝑬 𝑭𝑶𝑼𝑵𝑫𝑨𝑻𝑰𝑶𝑵 𝑶𝑵 𝑻𝑯𝑬 𝑩𝑬𝑺𝑻 𝑪𝑶𝑼𝑹𝑺𝑬 𝑶𝑭 𝑨𝑪𝑻𝑰𝑶𝑵.
The 4 initiatives proposed here are based on all our research around not only what EOSIO
requires, but also what is demanded by other communities in the blockchain space.
Recommendations 1-3 form the base requirement that any new blockchain tries to adapt to
promote a healthy foundation to build upon from a security point of view.
Recommendation number 4 is a relatively new proposal we have seen made in Ethereum. It
would be very advantageous for EOSIO to adapt this type of approach. EOSIO core technology has several distinct advantages making it easier to adapt this type of solution. Albeit a large
undertaking and will require multiple stakeholders across all working groups to decide on the best approach it will have a profound effect on the underlying trust of the system.
More on https://medium.com/eos-network-foundation/audit-blue-paper-3568c7ef863e