Hello, My name is KABIOLA FRAME, a ChallengeDac application user and a community member of challengeDac application. My username on the ChallengeDac application is @Kabioail34ft
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.
𝕋𝕙𝕖 𝕔𝕠𝕟𝕥𝕖𝕟𝕥 𝕚𝕤 𝕝𝕚𝕤𝕥𝕖𝕕 𝕓𝕖𝕝𝕠𝕨
𝗖𝘂𝗿𝗿𝗲𝗻𝘁 𝘀𝗼𝗹𝘂𝘁𝗶𝗼𝗻𝘀 𝘁𝗵𝗮𝘁 𝗲𝘅𝗶𝘀𝘁 𝗶𝗻 𝘁𝗵𝗲 𝗰𝗼𝗺𝗺𝘂𝗻𝗶𝘁y
𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻𝘀 𝘁𝗵𝗮𝘁 𝗮𝗿𝗲 𝗱𝗲𝗺𝗮𝗻𝗱𝗲𝗱 𝗯𝘆 𝗰𝗼𝗺𝗺𝘂𝗻𝗶𝘁𝘆
𝗘𝗾𝘂𝗶𝘃𝗮𝗹𝗲𝗻𝘁 𝘄𝗼𝗿𝗸 𝗱𝗼𝗻𝗲 𝗶𝗻 𝗼𝘁𝗵𝗲𝗿 𝗲𝗰𝗼𝘀𝘆𝘀𝘁𝗲𝗺𝘀
𝗔 𝗹𝗶𝘀𝘁 𝗼𝗳 𝗶𝗻𝗶𝘁𝗶𝗮𝘁𝗶𝘃𝗲𝘀 𝘁𝗵𝗮𝘁 𝗰𝗼𝘂𝗹𝗱 𝗶𝗺𝗽𝗿𝗼𝘃𝗲 𝘁𝗵𝗲 𝗘𝗢𝗦 𝗲𝗰𝗼𝘀𝘆𝘀𝘁𝗲𝗺
𝗔 𝗹𝗶𝘀𝘁 𝗼𝗳 𝗿𝗲𝗰𝗼𝗺𝗺𝗲𝗻𝗱𝗮𝘁𝗶𝗼𝗻𝘀 𝘁𝗼 𝘁𝗵𝗲 𝗳𝗼𝘂𝗻𝗱𝗮𝘁𝗶𝗼𝗻 𝗼𝗻 𝘁𝗵𝗲 𝗯𝗲𝘀𝘁 𝗰𝗼𝘂𝗿𝘀𝗲 𝗼𝗳
In this paper we provide our research and initiatives around improving the overall security of
EOSIO blockchains. Our 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 within developer communities which can only be achieved by giving them the right toolsand 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 userbase 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 theunderlying 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

A. 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 intermediate 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.

The benefits paid for service and won’t guarantee to cover the same depth as amanual security audit, 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:

* 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.

* 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 development language, which allows us to see the developer’s enthusiasm for developmenton EOS.
Based on our research and speaking to stakeholders within the EOSIO community, we have listed some of the key parts that we feel are demanded by the community that 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 harness 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 performing 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.
The reason is that 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. If all developers in EOSIO start using the same list of SDKs that are constantly updated to account for the latest security issues on EOSIO it helps to improve the overall security of smart contracts as it prevents developers from making the mistakes that are easily avoidable.
Demanding 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 scrutinised, especially if your code base constantly changes or has
multiple flavours.And the is actually because having a well run bug bounty programme will attract the best of the hacker community to im￾prove 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.

Demanding ethical hackers want to participate in EOSIO but will only invest the time and effort once we define and start a well run Bug Bounty programme.
C. Contract upgrade authorization DAO

In 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.

You can of course remove the ability for anybody to update the smart contract which creates trust between the users and the smart contract owners, however this prevents any future updates to the smart contract which would be required if bugs or security vulnerability are identified that require remedy.
So you are left in a position where you need some type of multi-signature scenario that can
facilitate trust between users and smart contract owners and allow the smart contract owner the ability to make updates if and when required in a timely manner.

The reason is that as 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 own￾ers the ability to make updates to their software.
Base on demand, The community and smart contract owners both require this type of functionality. dApp owners want their user base to trust them but also have the flexibility to update their dApps as and when required. Although it’s never possible to fully promise that a dApp the community is using is not at risk from being hacked or that the owners have good or bad intentions, providing this additional layer of trust helps create more trust between the community and dApp owners.
Researching other blockchains we have provided a list of security related content and products that are generally always available on top blockchain protocols, the overall general theme of how security is approached is very similar across all blockchains.
We also cover 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

We found that in Ethereum a github REPO exists that is trying to list all the current smart contracts, 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.”
Here, follow the list of ETH EVM chains currently supported includes:

1. Etherum Mainnet

2. Optimistic Ethereum

3. Binance Smart Chain

4. xDAI

5. Fuse

6. Polygon

7. Fantom Opera

8. Arbitrum

B. Open source Security tools

The description is 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. The common and nice to have features that are present in these tools are:
Identifies the error, the type of error, it’s severity and where it occurs in the source code.
Easily integrates into continuous integration and SDKs.
APIs are available to allow developers to write custom analyses.
Execution is very fast.
Code is mostly open source and maintained by the security and developer community.
The issues to avoid developing these tools in obscure languages and keeping the source code closed. Most of these tools are open source and developed in a programming language that is well suited for such analysis like Python, however there are some examples like Solana, where the only tool available is closed source which limits community involvement and stifles the growth of the tool

C. Software libraries for secure smart contract development

These software development libraries focussed 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.It is usually led by the official development, or developed by a well-known project party.
Development libraries are usually examples of applications, such as token, NFT, lending, swap, governance, etc. Some provide functions commonly used in contract development, such asthe safemath library that provides functions for arithmetic calculations that prevent overflow.

These secure development libraries have excellent code quality, which is specifically
manifested in:

• Each type of application has a complete function realization;

• Simple and modular code;

• Function and variable naming methods with clear meaning and consistent style;

• Variable and function function annotation description;

• Comprehensive unit testing;

• Support general package management tools, such as npm, cargo;

• After a more comprehensive security audit;
Issues to avoid is
One-time outsourcing development should be avoided, the development library should be continuously updated for security, and technical support should be provided to the community
as much as possible.

Based on all the current solutions that exist in the community, what’s demanded by the community 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
our baseline is established EOSIO’s unique design will allow us to move a step above other blockchains.

Currently no service exists where the community can verify that the current smart contracts
code they are interacting with has been audited and deemed as secure, nor is there a centralized location for auditors to publish their audit findings and associated information.


Establish a contract source code verification platform and an audit information disclosure platform which will make it easy for the community to verify the security of the smart con￾tract they are interacting with. Community includes users, other applications like wallets and exchanges.

Benefits to EOSIO

1. Exchanges can verify security of smart contracts by verifying the onchain hash matches

the hash of last audit performed.

2. Wallets can integrate with API using well maintained standards to provide a stamp of ap￾proval against smart contracts used during interactions.

3. Users can easily verify security of applications via wallets and or by visiting the proposed

frontend which would make it easy to view any application, it’s associated smart contracts

and the status of the audits.

1. On chain contract to push new audits: Allow security auditors to push new completed au￾dits to chain either via foundation or via MSIG. Each audit should contain:

a. Account address where the contract is loaded.

b. SHA256 hash of compiled WASM that audit was performed on.

c. Code repo URL.

d. Date of audit.

e. Auditor name.

f. Auditor email address.

g. Link to certificate if applicable.

h. Link to report if public.

i. Result: passed or failed
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.
List of common security pitfalls when writing EOSIO

This is a very easy win and a good start to help steer the developer community into creating robust and secure smart contracts. It also acts as a base for future tooling such as the automated security toolset.
Read more on https://medium.com/eos-network-foundation/audit-blue-paper-3568c7ef863e

One again, I am kabiola frame.


Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store