SlideShare une entreprise Scribd logo
1  sur  71
Télécharger pour lire hors ligne
EOS Core+
Blue Paper
Part I
2022
Table of Contents
Table of Contents��������������������������������������������������������1
I. Introduction�������������������������������������������������������������������3
I. Overview ���������������������������������������������������������������������������������������3
II. Team ���������������������������������������������������������������������������������������������4
III. Phases �����������������������������������������������������������������������������������������4
1. Launchpad�������������������������������������������������������������������������������4
2. Lift-Off�������������������������������������������������������������������������������������5
3. Propel���������������������������������������������������������������������������������������6
IV. Additional considerations ����������������������������������������������������7
1. Education����������������������������������������������������������������������������������7
2. Business���������������������������������������������������������������������������������8
3. RD�������������������������������������������������������������������������������������������9
V. Summary �������������������������������������������������������������������������������������9
II. Evaluation of the Current EOS
Ecosystem�������������������������������������������������������������������������10
I. Overview �������������������������������������������������������������������������������������10
II. Required developer guidelines identified by the
community �������������������������������������������������������������������������������������10
1. Why EOSIO blockchain?���������������������������������������������������10
2. Real-life use cases
�������������������������������������������������������������10
3. Role-specific developer guidelines
�������������������������������11
III. Required EOSIO protocol information identified by the
community ��������������������������������������������������������������������������������������12
1. Ricardian contracts
��������������������������������������������������������������12
2. Nodeos internal documentation������������������������������������13
3. Plugins Solutions and Examples configuration
��������13
IV. Conclusion ��������������������������������������������������������������������������������14
III. EOSIO Infosphere Evolution ��������������14
I. Overview ��������������������������������������������������������������������������������������14
II. Audience analysis 
��������������������������������������������������������������������15
III. Current state of documentation ��������������������������������������� 18
1. Developers.eos.io��������������������������������������������������������������� 18
2. Docs.telos.net��������������������������������������������������������������������� 18
3. Developer.wax.io ��������������������������������������������������������������� 18
4. Blogs��������������������������������������������������������������������������������������� 18
5. GitHub ����������������������������������������������������������������������������������� 18
6. Books��������������������������������������������������������������������������������������19
7. Documentation for enterprise����������������������������������������19
IV. Learning challenges ������������������������������������������������������������ 20
V. Infosphere development proposals ������������������������������ 20
1. Information coordination group (editors-in-chief)�� 20
2. Content management platform������������������������������������21
3. End-user documentation and tutorials ���������������������22
4. High-level articles for managers���������������������������������22
5. Back-end software architecture guides �������������������23
6. Front-end software architecture guides�������������������24
7. Reference documentation
�����������������������������������������������24
8. System administration guides���������������������������������������25
9. Video tutorials���������������������������������������������������������������������26
10. Curated catalogue of resources���������������������������������26
IV. EOSIO System Evolution�����������������������27
I. Overview �������������������������������������������������������������������������������������27
II. Roadmap for nodeos improvements �����������������������������27
1
EOS Core+ Blue Paper
	 EOS Core+
1. Project name for EOSIO community distribution ���27
2. Setting up the development process�������������������������27
3. Redesign the Blockvault plugin������������������������������������ 28
4. Features and intrinsics in plugins�������������������������������� 28
5. Build scripts for standalone cleos+keosd�����������������29
6. Nodeos internals documentation ������������������������������30
7. Fix the broken print output����������������������������������������������30
8. Clean up the nodeos test suite������������������������������������30
9. API endpoint for speculative transaction status���� 30
III. Roadmap for EOS system contract improvements ��31
1. Documentation cleanup����������������������������������������������������31
2. Accumulating BP rewards������������������������������������������������31
3. Contract pays������������������������������������������������������������������������31
4. Staking, REX, voting���������������������������������������������������������32
5. Project token names in eosio.token ���������������������������32
6. Unsellable RAM�����������������������������������������������������������������32
IV. Topics for research and design ���������������������������������������32
1. RocksDB: undefined future���������������������������������������������33
2. Native EVM plugin�������������������������������������������������������������33
3. Getter methods in contracts�����������������������������������������33
4. Advanced account permissions���������������������������������� 34
5. Horizontal scalability�������������������������������������������������������� 34
6. State memory scalability������������������������������������������������ 34
7. Fast finality�����������������������������������������������������������������������������35
8. Evolution of economy and governance models�����35
V. Smart Contract Tooling Evolution36
I. Overview ������������������������������������������������������������������������������������ 36
II. Current picture 
������������������������������������������������������������������������ 36
1. Tools maintained by Block.one������������������������������������� 36
2. Community tools ���������������������������������������������������������������37
III. Gap analysis: missing pieces �������������������������������������������37
IV. Smart contract tooling roadmap �������������������������������������37
1. Smart contract testing framework �������������������������������37
2. Contract deployment automation framework�������� 39
3. Library of contracts and templates���������������������������� 39
4. Prepackaged tools for Windows and macOS��������40
5. Ricardian contracts framework������������������������������������40
6. Smart contract development kits roadmap��������������41
7. Low-code / no-code framework�����������������������������������42
VI. EOSIO for Business and
Government�������������������������������������������������������������������� 43
I. Overview ������������������������������������������������������������������������������������ 43
II. Suite of tools �����������������������������������������������������������������������������47
III. Premier Technical Support ����������������������������������������������48
IV. Blockchain as a Service (BaaS) �������������������������������������� 49
1. Consulting���������������������������������������������������������������������������� 49
2. Training and certification��������������������������������������������������51
3. Generic enterprise needs�����������������������������������������������52
4. Miscellaneous���������������������������������������������������������������������52
5. Business+�����������������������������������������������������������������������������52
V. EOSIO for Business RD proposals ������������������������������ 53
1. Enterprise signing portal
�������������������������������������������������� 53
2. Blockchain configurator��������������������������������������������������54
3. Block explorer�������������������������������������������������������������������� 55
4. History API �������������������������������������������������������������������������� 55
5. Enterprise developer toolkit������������������������������������������ 55
VI. Conclusion ����������������������������������������������������������������������������� 56
VII. Future Tech Research and
Development �����������������������������������������������������������������57
I. Overview �������������������������������������������������������������������������������������57
II. Self-sovereign identity for EOSIO �������������������������������������57
1. Legacy digital identity: the problems�������������������������� 58
2. Self-sovereign identity: the solution�������������������������� 59
VIII. Enabling SSI on EOSIO �����������������������62
I. Overview �������������������������������������������������������������������������������������62
1. EOSIO DID specs���������������������������������������������������������������62
2. W3C verifiable conditions�����������������������������������������������62
IX. EOS Legal Support��������������������������������������64
I. Stage one: knowledge and referral database ��������������64
1. Overview��������������������������������������������������������������������������������64
2. Fields of interest���������������������������������������������������������������� 65
3. Delivery
���������������������������������������������������������������������������������� 65
4. Budget estimates�������������������������������������������������������������� 66
II. Stage two: establishing international principles ���������67
1. Overview���������������������������������������������������������������������������������67
2. Practical use�������������������������������������������������������������������������67
3. Delivery
�����������������������������������������������������������������������������������67
4. Budget estimates�������������������������������������������������������������� 68
X. Index���������������������������������������������������������������������������������� 69
2
EOS Core+ Blue Paper
	 EOS Core+
I. Introduction
I. Overview
This document presents a series of recommendations for the improvement of the EOSIO
blockchain protocol. It forms part of a larger proposal developed by ‘Core+’, a working group
commissioned by the EOS Network Foundation (ENF) to identify existing gaps in the frame-
work and creative routes to expand its offerings. It has been conducted alongside a number of
other ENF-commissioned working groups, each targeting a distinct area of EOSIO.
A multitude of causes created voids in the support for and visibility of EOS and EOSIO net-
works. The role of Block.one, who have historically been responsible for the resources to sup-
port the uptake of EOSIO, has diminished in the ecosystem. This requires new resources to be
developed and disseminated. Particular attention must be given to the onboarding, learning,
and tools that are needed to empower developers, system admins, IT and software architects,
and infrastructure and support engineers.
The proposal has been structured in such a way as to accommodate different audiences. We
did not want to submit a 200-page document to the community, but also did not want to throw
away any of the valuable information and research conducted by our partner network. As a
result, the proposal is divided into three:
•	 A one-pager describing the essence of Core+
•	 The main blue paper (this document)
•	 Supporting documentation which will be presented in GitBook for further reading
The centre of the proposal is the recommendation of a three-phase plan. Supported by the
information detailed in the chapters below, our goal is for the community and ENF to be able to
make an informed decision on the best way forward for EOSIO.
3
EOS Core+ Blue Paper
	 EOS Core+
II. Team
A diverse team makes up the Core+ working group. Zaisan, who leads the group, was founded
by EOS Amsterdam, EOS Dublin, Cryptolions, and EOS Barcelona. It is made up of seasoned
professionals with diverse skill sets, including senior developers, infrastructure administrators,
project managers, cybersecurity, and legal experts. It brings together some of the most senior
minds in the EOSIO ecosystem and decades of collective experience in Big Four consulting
and project management. Zaisan has a footprint across six countries in Europe, with a global
partner network that has been instrumental to the research.
Zaisan has been supported in this research by EOS Costa Rica, CTIC, Eurecat, EOS Bulgaria,
and Rewired.one, and all of the other community contributors who helped along this journey.
They selected this set of teams because of their unique position in the market. Each has expe-
rience with EOS development and also hands-on experience delivering EOSIO-based projects
to startups, SMEs, MNCs, and universities. For more information on the contributing team
see here.
III. Phases
Using the analogy of a space shuttle, we have named the three phases for the development of
EOSIO ‘Launchpad’, ‘Lift-Off’, and ‘Propel’.
1. Launchpad
Before anything else, the entire EOSIO craft needs to be stabilised on a ‘Launchpad’ and
pointed in the right direction. If not, it will take off on the wrong path.
Launchpad involves a comprehensive review and update of the currently available docu-
mentation and training for EOSIO. These have been neglected for years and must become
community-owned and managed in order to provide a stable base to build upon.
This is the minimum required to produce value for the network, filling the major technical
gaps identified by Zaisan, Rewired.one, EOS Costa Rica, CTIC, TestingSaaS, Eurecat, the
individuals interviewed, and the other community collaborators.
4
EOS Core+ Blue Paper
	 EOS Core+
The Launchpad phase is a necessary prerequisite in order to start any of the other initia-
tives in ‘Lift-Off’ and ‘Propel’. Current and up-to-date information is needed first, then an
audit for what is missing and should be prioritised.
Budget estimate: see ‘Budgets’.
2. Lift-Off
Once the craft is securely on the Launchpad, it needs to be prepared for ‘Lift-Off’. The
team needs to ensure that all of the modules are in place to give the best possible chance
of a successful voyage.
The focus here is the community: multi-chain compatibility, global collaborations, frame-
works for incentives, and enhanced onboarding (partnerships, events, working groups,
etc.). A key aspect of this package is the addition of business-focused solutions. Another is
the addition of comprehensive templates for easy deployment of applications and tools on
the chain. Guides and templates are needed for new blockchain implementations such as
DeFi 3.0 and GameFi.
On the social and onboarding side, Lift-Off will include a framework for attracting as many
new developers, community members, and business partners as possible. This will take
the form of high-quality videos, incentives, and high-profile research pieces.
Lift-Off will incorporate regional representatives to ensure that it is relevant to global
communities (some use cases in China may not be as applicable in the Netherlands). It is
essential to make sure that we provide support for non-English speaking communities.
Valuable partnerships with appealing companies, IT analyst firms, and institutions will
contribute to the presence and visibility of EOSIO. We will build on the previous options by
targeting educational institutions to get EOS / EOSIO included in Computer Science de-
partments around the world. Zaisan, Costa Rica, and Rewired all have university connec-
tions and can quickly open these lines of communication to empower the next generation
of EOS rockstar developers.
Lift-Off will also incorporate a legal framework that can help projects get past the POC
stage and into a live environment.
Budget estimate: see ‘Budgets’.
5
EOS Core+ Blue Paper
	 EOS Core+
3. Propel
After Lift-Off, there needs to be the correct fuel required to ‘Propel’ the craft to the re-
quired destination.
Propel includes all of the above with augmented features — the focus becomes speed and
scale, supporting many millions of new users and communities from around the world.
The task Propel addresses is how EOS can be brought to the major business and pop-
ulation centres of the world—Europe, India, East Asia, and the Americas. However, each
region has different customs, laws, and business practices. Within Propel we will need to
establish ‘boots on the ground’ within these locations with specific tools and use cases
per region. Examples of areas that will need addressing include:
•	 General Data Protection Regulation (GDPR)
•	 California Consumer Privacy Act (CPA)
•	 Financial Action Task Force (FATF)
•	 India Stack
•	 Persons Information Protection Law
The CCID Research Institute of the Ministry of Industry and Information Technology of
China publishes the Global Public Chain Technology Evaluation Index. According to their
rankings, EOS is the best blockchain, ranked for basic/tech, applicability, and creativity.
This promises a wider and easier acceptance of EOSIO-based products and solutions in
China.
The Propel phase will have a dedicated RD team who are constantly maintaining and
updating the codebase to keep EOS / EOSIO competitive and a player on the global block-
chain stage.
Budget estimate: see ‘Budgets’.
6
EOS Core+ Blue Paper
	 EOS Core+
IV. Additional considerations
There are certain aspects that we feel are required but there are also areas that we feel should
be considered as they will greatly increase the reach, userbase, usability, and legal frameworks
required for EOS / EOSIO to perform in the global blockchain market once again. These can be
broken down into:
1. Education
45,000 ‘students’ began courses through the Block.one educational funnel. However, this
did not result in any significant growth in the number of EOSIO developers or community
members. Nonetheless, it demonstrated that there is a huge demand for education in the
blockchain space, but there need to be clear next steps and a support network for people who
are interested.
As such, we need to consider what support there is to bring students to a level where they are
actively participating and contributing to the success of the network. We believe this should be
trialled as time-based training where a student joins with a class for a term and there is a clear
way to build connections and networks. These could either be delivered as EOSIO communi-
ty-led courses or in partnership with existing universities.
Educational modules could be segmented according to the target audience, for example:
Executives - One-pagers, infographics, videos
Developers - Comprehensive step-by-step guides (written form), multilin-
gual support / documentation, forums, and groups (Discord, Telegram)
Infrastructure Administrators - Debugging guides (video and text), script
templates, sample infrastructure set-ups
7
EOS Core+ Blue Paper
	 EOS Core+
Zaisan, Costa Rica, CTIC and Rewired.one all have university connections and can
quickly open these lines of communication to empower the next generation of EOS
rockstar developers.
2. Business
Adoption by startups, SMEs, and MNCs is instrumental to the success of any chain. For busi-
nesses to enter a certain blockchain there are minimum requirements that must be met from
compliance, legal, performance, and operational perspectives. This would include such indus-
try use cases as:
Technical integrations with high-profile enterprise stacks. APIs and connectors to
rapidly implement EOSIO solutions to SAP, Oracle, Microsoft, CISCO
Other integrations, support, and documentation for IoT, RFID, Identity solutions (DID,
VC, IDM)
Use case templates to allow quick deployment of POCs and use cases without com-
plex architecture—here we will pay special attention to upcoming ‘hype’
GameFi use case (rewards, incentives, promotion, recommendations,
Play2Earn, leaderboards)
NFT use cases (invoices, materials passports, collectables, rewards, tickets)
DeFi use cases (borrowing, lending, staking, trading)
8
EOS Core+ Blue Paper
	 EOS Core+
3. RD
A dedicated team is needed to continue researching bleeding-edge technology and working
on how to integrate that with the current ecosystem. These are areas such as IoT, decentral-
ised identity, VR solutions, scaling solutions, decentralised storage, and other fields that need
further research. The RD team should take a ‘partner first’ approach to make sure that best-
in-class technology exists. Valuable partnerships with well-known companies and institutions
will contribute to the presence and visibility of EOSIO. If there are no partnership opportunities
available, then the team can look at research, development, and architecture ‘in-house’.
V. Summary
What is central to this entire proposal is an outline and a list of suggestions for what needs to
be done in order to give EOS / EOSIO the competitive advantage it once had. The chapters
below provide the supporting detail and evidence for the recommendations made. For further
supporting information and the full extent of research that accompanied this Blue Paper, see
our GitBook page.
To find out why this is important, click here.
9
EOS Core+ Blue Paper
	 EOS Core+
II. Evaluation of the Current
EOS Ecosystem
I. Overview
There currently exist gaps in the information
and support for EOSIO. Such gaps are liable
to cause problems for developers, and in the
worst cases could result in problems for the
end-user due to poor implementation of the
protocol. The goal of this chapter is to assess
the current state of EOS from the perspec-
tive of new users and developers, identifying
gaps to be closed.
II. Required developer guidelines identified by the community
1. Why EOSIO blockchain?
Different protocols with powerful character-
istics fit different necessities. Not all of them
are recommended and none can solve every
problem. To avoid mistakes in decision mak-
ing we need to provide clear documentation
to help tech lead developers to guide their
companies to the right course without having
to become instant experts. The two basic
questions are:
1.	 Why seek a solution in blockchain?
2.	 What protocol is most likely to fix
the problem?
It is very important that the documentation is
not only oriented for developers but also for
non-techy decision-makers across different
fields to help them to decide if integrating an
EOSIO private or public blockchain network
would help their company.
2. Real-life use cases
When speaking of blockchain, people might
think about security, trust, transparency,
integrity, and most of all immutability. But
all these do not necessarily apply to all use
cases, it all depends on each specific sce-
nario. Solutions can be forced to solve prob-
lems, however, that isn’t the best idea with
a blockchain.
Exposing and explaining real-world applica-
tions could help developers and interested
10
EOS Core+ Blue Paper
	 EOS Core+
people to make better decisions about
whether to use this technology or not. Even
better, if blockchain technology is used, to
apply it taking advantage of all of the nice
features of EOSIO. For example, one could
use the multi-sig feature that restricts ac-
tions to be executed only with the consent
of all the responsible parties specified in
the permissions.
Real-world examples are the best way to
introduce EOSIO tools, technologies, and
configurations to improve the understanding
of the general public and decision-makers.
Most guides explain how to do a task but fail
to explain why or what are the best scenari-
os that could fit that necessity, and when to
implement these.
3. Role-specific developer guidelines
Software development is divided into vari-
ous phases, each one of them is focused on
specific rules to achieve the best final prod-
uct but those rules need to be placed some-
where, to allow coding professionals to get
into the right spot without having to dive too
deep, constantly reinventing the wheel.
a. Front-end
Applying best practices helps contributors to
understand the code easily and thus speed
up the improvement and integration process
for any tools. It also helps new developers to
learn how to do things right without resort-
ing to empirical learning already covered by
others in the past.
Specifying the options for building front-end
projects with suggested architecture, tech-
nologies, security principles, wallet integra-
tions, and many others will definitely make
any front-end developer’s life much easier,
while at the same time resulting in a more
complete final product.
b. Back-end
Back-end development is like the chef in
a restaurant, without whom there is not
much to do for the front-end. If the chef in
the kitchen is working for another restau-
rant too, this could produce unavailability of
food and service, causing the front-end to
lose customers.
This metaphor exemplifies what happens if
a wrong design is applied. It is easy to un-
derstand why it is really important to have
clear guidance on the steps, phases, and any
other helpful things that might improve the
process of correct software development
in terms of design, architecture, libraries,
protocols, security, and any other important
criteria that are applicable.
c. DevOps and CI/CD
In a developer team, there could be between
2 and 5 members working on the same
project and applying new integrations. Some
other developers could be there just for
performance improvement, others for design
changes, and so on. It could be very expen-
sive to pay someone to only keep manually
updating all the changes that are integrated
11
EOS Core+ Blue Paper
	 EOS Core+
into a repository. It is necessary to correctly
set up DevOps tools that help the team’s
overall productivity, reduce project cost, and
help to better shape the production process
via more accurate and continuous feedback.
Specifically for EOSIO, using a real example,
a project could contain many services that
need to be updated with any minor change
that happens, for example, an update to the
wallet, the back-end, the front-end, or any
other service that a project could be using.
All of those updates will be very costly in
terms of time if DevOps along with CI/CD is
not applied correctly.
d. Setting up a developer environment
Each project could have a different develop-
er environment depending on the use case,
but a core of base tools may be useful in all
instances. For example:
What are the recommended IDEs for
C++ developers?
Which C++ smart contract compiler is best
to fit a given use case?
What is the best blockchain environment to
test the smart contract?
It won’t make any difference in the logic but
some people could notice that certain pl-
ugins, blockchain environments, and others
bring better compatibility, productivity, ease
of understanding, and so on. Correct guid-
ance could improve team performance.
III. Required EOSIO protocol information identified by the
community
1. Ricardian contracts
The following gaps in the implementation of
Ricardian contracts have been identified by
the community:
a.	 Multi-lingual Ricardian contracts
The following suggestions would
strengthen the Ricardian Contract
to spread to a general adoption by
the community.
b.	 HTML-safe Ricardian contracts
The framework needs to allow the pub-
lishing of multiple translations of the
same document.
c.	 Wallet support and user-friendly display
Current implementations do not provide
easy means for wallets and browsers to
display the Ricardian content. The doc-
ument needs to be easy to display in a
user-friendly manner.
12
EOS Core+ Blue Paper
	 EOS Core+
d.	 Signatures on Ricardian contracts
It might be beneficial to use the publish-
er’s signature as part of the Ricardian
contract (similar to PGP signatures).
In general, a Ricardian contract is a hu-
man-readable document that comes togeth-
er with a smart contract and describes its
expected behaviour. It may also serve as a
legal agreement, although the details of legal
applicability have not been explored.
Developers often publish their Ricardian
contracts, as is normal in blockchain, to
maintain transparency. However, since there
is no clear standard to follow there is some
variation in developer implementation. The
fact this is open to individual interpretation
results in discrepancies that could cause
tools to malfunction.
Providing Ricardian Contract examples
following a standard will help to remove any
openness of interpretation and will leave only
one way to do things, so all types of content
will have the same underlying architecture.
2. Nodeos internal documentation
The following gaps have been identified in
the nodeos internal documentation:
•	 Data serialisation
•	 Building the Merkle trees
•	 Transaction signing
•	 Resource management
•	 Core protocol functionality
•	 Core protocol logic
•	 Accumulating block producer rewards
•	 State history solutions
The nodeos component is modular and
provides a set of nodeos plugins to configure
a node according to specific needs. Knowing
how to do a certain configuration or the best
place to put a node in a network is difficult,
there is not much documentation on how to
configure a producing node, peering node,
chain API node with its extension, or a State
History API.
3. Plugins Solutions and Examples
configuration
The nodeos component is modular and
provides a set of nodeos plugins to configure
a node according to specific needs. Knowing
how to do a certain configuration or the best
place to put a node in a network is difficult,
there is not much documentation on how to
configure a producing node, peering node,
chain API node with its extension, or a State
History API.
13
EOS Core+ Blue Paper
	 EOS Core+
III. EOSIO Infosphere Evolution
I. Overview
This chapter outlines various streams of information related to the EOSIO blockchain ecosys-
tem and suggests ways to build and deliver this information to its consumers.
Many different teams will work on creating and organising the content. This chapter aims to
provide general guidelines to writers and engineers and to suggest a possible structure.
Owners and C-level
executives
Software developers
Technical leads, IT archi-
tects, software architects
Infrastructure and
support engineers
IV. Conclusion
The need for deeper support of EOSIO devel-
opers is clear, and there is potential to capture
new users by clarifying and advertising the
unique features and benefits of the EOSIO
protocol. Many business, administration, and
governmental requirements would be ideally
solved with EOSIO, but not if those organisa-
tions are unaware of EOSIO’s suitability, or if
their developers are put off by the lack of doc-
umentation. The detailed information provided
by the existing community in identifying these
shortcomings is invaluable in the process of
overcoming them.
To find out why this is important, click here.
14
EOS Core+ Blue Paper
	 EOS Core+
II. Audience analysis
Information consumers can be categorised in a number of different ways. Knowing the type
of consumer will help us to organise and deliver the information in an optimal way to help the
decision-makers understand the benefits of EOS and make the right choices.
Decision Makers:
Each decision-maker will have their own level of expertise and experience with EOSIO
blockchains:
Each level of reader is typically looking for different kinds of information.
Newbies will need:
•	 Articles and videos explaining the bigger picture (how it all works, what it does, what the
major components are)
Intermediate
Already in EOSIO projects, looking for a reference in a specific topic.
Newbie
Zero experience with EOSIO, probably some knowledge about Ethereum
and Bitcoin. They first need to understand how it all works in a general way.
Expert
Top-level EOS partners able to edit, review and add more content.
15
EOS Core+ Blue Paper
	 EOS Core+
•	 Quick-start tutorials for architects and developers about typical applications and
basic tasks
•	 High-level overviews of infrastructure components for infrastructure engineers (their com-
munication, system requirements)
Intermediates with some knowledge of EOS will need:
•	 Guidelines and examples (how to complete basic tasks, system guidelines)
•	 Software references (APIs, libraries, further quickstarts, guides)
Different readers prefer different presentation formats. Managers and decision-makers like
seeing pitch decks with detailed diagrams. Newbies may prefer video tutorials, whereas inter-
mediates want more detail in the form of text.
Newbies, intermediates, experts – anyone unfamiliar with EOS will need:
•	 Straightforward ‘how-to’ guides for onboarding, using the blockchain, buying tokens, and
wallet security
•	 Easy ways to find suitable blockchain applications (dApps) and smart contracts
•	 Links to videos and social media campaigns to raise awareness and fuel new ideas
Business decision-makers will also want to know the business benefits – they will need:
•	 Executive summaries, views of high-level architecture
•	 Typical real-life use cases with actual examples
•	 Success stories, real-life business cases, do’s and don’ts
•	 Information about any available service providers, infrastructure providers, as well as de-
velopment teams, integration, consulting, and training companies within EOS
•	 Information about other existing public blockchains and their distinctive features
System and software architects who define the development strategy need to have:
16
EOS Core+ Blue Paper
	 EOS Core+
•	 High-level overviews and tutorials on EOSIO technology
•	 A full catalogue of FOSS and commercial software and tools
Software developers who deal with hands-on coding and software design will want to see
deep dives into the technology itself, including:
•	 Tutorials and guides for smart contracts, middleware, front-end
•	 Explanation of the bigger picture (system components, infrastructure, and APIs)
•	 Reference documentation for APIs and SDKs
•	 Catalogue of EOSIO open-source libraries and tools
•	 Catalogue of open-source projects built on EOSIO
System administrators responsible for planning and maintaining all the infrastructure that runs
the blockchain nodes will need to know about:
Covered Missing
	
✓ Introduction (general overview,
basic terminology)
	
✓ ‘Getting started’ guide
	
✓ Guides on smart contracts
(protocols, permissions)
	
✓ Test network startup guide
	
✓ Tutorials for gaming (Tic-tac-toe and
Elemental Battles)
	
✓ Manuals (nodeos and utilities, SDK,
API references)
	
✓ Resources (links to community groups, tools,
and public blockchains)
	
✗ No real-life use cases or examples
	
✗ No ‘why’ (newbies are not told why each tutorial
is needed, what their goal is, what they should
learn, or what they will be able to move on
to next)
	
✗ Outdated information in some guides
	
✗ Missing details and dependencies in
development environment installation guides
	
✗ Lack of explanation of local test blockchain vs.
public blockchain
	
✗ No help for Windows or macOS users (guides
and tutorials are aimed at Linux users)
	
✗ Too little information for front-end developers
17
EOS Core+ Blue Paper
	 EOS Core+
•	 Infrastructure planning and capacity management
•	 Software installation and configuration guides
III. Current state of documentation
Information is currently scattered across six independent information sources, making it
sometimes tricky to find answers to particular topics, with some not covered at all.
1. Developers.eos.io
The EOSIO Developer Portal holds a large collection of the available EOSIO documentation.
The following table outlines the topics covered and the gaps where topics are missing.
2. Docs.telos.net
Provides general information about various components of Telos public blockchain, such as
EVM (Ethereum Virtual Machine), account creation, staking, etc.
3. Developer.wax.io
Explains components specific to the WAX public blockchain, such as the web wallet and RNG.
Some outdated guides describe services that will soon be unsupported. Minimal references to
EOS, mainly about how to deploy EOS dApps on WAX.
4. Blogs
There are active EOS community members posting useful articles on various technical topics
related to EOS and WAX.
5. GitHub
A code hosting platform for collaboration on open-source projects at different levels of code
maturity and documentation. There is no comprehensive catalogue of EOS-related projects or
of EOS.
18
EOS Core+ Blue Paper
	 EOS Core+
6. Books
‘Learn EOS Development’ by Christoph Michel - a detailed guide for any developer who wants
to start with EOSIO smart contracts.
7. Documentation for enterprise
When enterprises consider a technology, they have a business problem that needs a solution.
They ask themselves: ‘Do we need a blockchain, or is a traditional database management
system sufficient to support our use case?’ We need clear examples and selection tools/flow
charts to help businesses assess the pros and cons of blockchain technology.
Once the decision to implement blockchain is made, the case for EOSIO needs to be made.
This is a straightforward sales story, driven by comparisons with competing blockchain solu-
tions, highlighting the flexibility, scalability, and security that only EOSIO can deliver. This
should also include such issues as running costs and, most crucially, environmental impact
linked to corporate social responsibility.
A single sign-on (SSO) platform, such as Microsoft Active Directory (MAD), is typically de-
ployed in an enterprise environment, storing user login credentials centrally. Once a user
authenticates, they have smooth access to all corporate platforms and applications.
To provide a similar SSO experience when introducing blockchain, we need to offer a pass-
wordless implementation of EOSIO, which can be provided by WebauthN, using either hard-
ware keys or biometrics for authentication. We need to supply clear documentation, combined
with use cases and demos, highlighting the ease of implementation. WebauthN is a significant
competitive differentiator for the EOSIO software ecosystem and may attract new users with a
security and compliance mindset.
A typical use case for enterprise customers is in long-term data retention policies that pro-
tect against or provide evidence for potential lawsuits. Furthermore, an enterprise must
demonstrate high levels of integrity to meet regulatory, audit, or compliance obligations.
Implementing a private blockchain within the customer environment with a hashing towards
the EOSIO public Mainnet demonstrates and secures the integrity of a chain of events. Re-
ordering or forking a private chain is easily identifiable. Anyone with access to both networks
can compare check-point data and determine the exact time the action occurred. This pro-
cess turns a hybrid blockchain solution into a tamper-evident system.
The solution needs to be clearly described, with a value proposition and accompanied by
practical implementation guides.
19
EOS Core+ Blue Paper
	 EOS Core+
How can the ENF help?
•	 Provide industry-specific views of how EOSIO can solve problems for a variety of use cas-
es (apart from four different case studies, there are no enterprise use-cases)
•	 Create a competitive analysis of how EOSIO compares to other blockchains for deploy-
ment, running costs, performance, environmental impact, etc.
•	 Improve the documentation of WTMsig, which helps block-producing nodes enjoy a safe
and secure highly available setup for block production
•	 Create specific documentation for high availability setups, which is key for
enterprise operations
•	 Provide documentation and guidance on which smart contract state storage to use in a
given scenario (ChainBase or RocksDB)
IV. Learning challenges
In summary, everyone is missing the bigger picture. Tutorials that explain the EOS logic and
other disparate information are all scattered across different forms of media without useful
best practice guides, real-life use cases, and concrete examples. This creates levels of frus-
tration and developers often have to go onto chats to find out what they need to know.
V. Infosphere development proposals
We recommend the community and EOS Network Foundation allocate the funds to address
these challenges.
1. Information coordination group (editors-in-chief)
The first step is to form a group to coordinate and maintain the overall information struc-
ture. Subsequently, it can assign tasks to content creators and manage the information
reference platform.
Benefits: information will be managed, organised, and easy to find for every kind of reader.
20
EOS Core+ Blue Paper
	 EOS Core+
Do-nothing option: information sources will continue to be incomplete, unmanaged, and devel-
opers and business customers will be less inclined to adopt EOSIO.
Budget estimate: see ‘Budgets’.
2. Content management platform
The next step will be to create a platform to help users navigate existing documenta-
tion and find links to the best sources. The following criteria need to be met in the content
management system:
•	 Long-term support
•	 Easy collaboration between content writers
•	 WYSIWYG editing for graphics and clear presentation
•	 Changes to tracking and document control
•	 Flexible permissions (a chief editor delegates rights to other authors)
•	 A navigation structure to help viewers find information as quickly as possible
•	 Ability to address different readers with direct links to subcategories
•	 No duplication of information (to define and structure this is a nontrivial task)
•	 Long-term ownership definition (DNS, hosting, content management)
•	 A reliable hosting solution (preferably backed by GitHub)
A long-term plan for developers.eos.io is needed:
Pre-requisites: the team of editors-in-chief needs to be formed and budgeted for.
Benefits: a consistently reliable place for aggregation and indexing of various EOS information
resources, and a publishing platform for content creators.
Option 1
Block.one keeps maintaining the
content, and we link to it; ENF and
Block.one coordinate their efforts in
content creation
Option 2
ENF takes over the website and
content ownership
21
EOS Core+ Blue Paper
	 EOS Core+
Do-nothing option: the EOS community will rely on various third-party content host-
ing solutions and EOSIO will continue to suffer from increasingly incomplete and
disparate documentation.
Budget estimate: see ‘Budgets’.
3. End-user documentation and tutorials
All blockchain users need guides and tutorials for simple daily tasks, such as:
Benefits: easier onboarding of non-technical and non-crypto-savvy users.
Do-nothing option: community forced to rely on self-organisation via forums and chats, with a
limited number of enthusiast groups creating the content beyond the EOS strategic vision.
Budget estimate: see ‘Budgets’.
4. High-level articles for managers
Business and technical management need comprehensive top-down ways to present the EOS
technology to C-level executives and decision-makers, covering the following topics:
•	 Blockchain operation: accounts, smart contracts, resources, permissions
Navigation of end-user wallet software: a catalogue of key managers, account manag-
ers, basic token transfers, etc. (focusing on all platforms, not just Linux)
Catalogue of end-user applications: blogs, informational websites, news
Explanation of Resources: CPU, NET, RAM and their management
Onboarding: keys and accounts creation, basic security
22
EOS Core+ Blue Paper
	 EOS Core+
•	 Blockchain infrastructure explanation: roles of different kinds of nodes, operational chal-
lenges, in house-skills required
•	 Blockchain applications: architecture, components, and communication
•	 Typical blockchain business use cases
•	 Overview of existing complete products and key functions (i.e. Upland, Emanate, DeFi
projects, etc.)
•	 Private vs. public blockchain: decision-helping guide showing budgets and costs
•	 Legal aspects: privacy, finances, custodianship, taxation
•	 Answering a government RFP: key points, references, how-tos
Benefits: executive and senior technical managers, as well as end-users and developers, will
be better informed about the EOS blockchain and its possibilities.
Do-nothing option: several consultancy groups are already in operation, and they present the
technology to their customers. This would continue as a local business initiative, however,
without support, they may gradually disappear.
Budget estimate: see ‘Budgets’.
5. Back-end software architecture guides
We need to fill the gaps in its current EOSIO technical documentation. New developers are
faced with a set of reference documents and a few disconnected articles, but nothing that
would explain the general logic of blockchain operation. This lack of documentation often
leads to bad design decisions, security breaches, and loss of money for users.
The following topics need to be covered:
•	 Blockchain applicability: where EOSIO fits the job and where it does not
•	 Smart contracts: basic design principles, do’s and don’ts
•	 Smart contract security guide: known threats and ways to mitigate them
•	 Back-end architecture guide: infrastructure, APIs, server-side security, scalability, etc.
•	 Sending and receiving payments: finality, forks, inline actions for transactions
•	 How-to and best practice: explaining typical usage patterns
23
EOS Core+ Blue Paper
	 EOS Core+
•	 Setting up the development environment: (IDE, etc.) Windows, Mac
•	 Reference projects: quickstarts, templates
•	 Troubleshooting guides: testing, debugging
Benefits: engineers will avoid common mistakes, their products will be brought to market with
quicker turnarounds, and quality control will be improved.
Do-nothing option: engineers will keep asking the same questions in development chats, and
will keep making mistakes that will throw their projects back, or open up security holes.
Budget estimate: see ‘Budgets’.
6. Front-end software architecture guides
Web and mobile application engineers need development and architecture guides. This area
of front-end development is very dynamic, so this has to be an ongoing effort. The following
guides are needed:
•	 User security: types of wallets and key management
•	 Resource management: how to keep RAM, NET, and CPU costs down
•	 Web application: frameworks and libraries
•	 Mobile application: frameworks and libraries
Benefits: developers will stop wasting time in community chats, and start delivering optimal
solutions that are cheaper to maintain and update.
Do-nothing option: application developers will continue to make common mistakes as a result
of using outdated libraries, tutorials, and insecure methods of handling users.
Budget estimate: see ‘Budgets’.
7. Reference documentation
So far most of the reference documentation has been maintained by Block.one. Should that
change, the community will need to keep the documentation up to date as an essential ele-
ment of any software development environment. This part of the proposal covers the refer-
ence documentation for the following topics:
24
EOS Core+ Blue Paper
	 EOS Core+
•	 Smart contract API
•	 Nodeos API
•	 Wallet APIs
•	 Other service APIs (such as Hyperion)
•	 Client libraries
•	 Third-party extensions for the EOS node software (nodeos)
Benefits: developers get complete and up-to-date documentation for their work.
Do-nothing option: the reference documentation will become increasingly outdated and obso-
lete, and the overall development quality will degrade.
Budget estimate: see ‘Budgets’.
8. System administration guides
Currently, whenever a new team needs to set up their EOSIO server infrastructure, they start
from scratch, fail, then order in bigger hardware and ask for advice within the community.
System administrators need help to plan and operate their environment. Topics to be covered:
•	 Hardware planning and sizing
•	 System setup scenarios and options
•	 Block producer guidelines
•	 Redundancy and fault tolerance
•	 Troubleshooting the blockchain nodes, emergency failures, and recovery
Benefits: overall blockchain stability and performance will improve, minimising unnecessary
costs and time loss.
Do-nothing option: system engineers will keep struggling to bring up their blockchain
nodes and will keep making common mistakes. It may potentially lead to application or core
blockchain degradation.
Budget estimate: see ‘Budgets’.
25
EOS Core+ Blue Paper
	 EOS Core+
9. Video tutorials
Many people say they prefer video tutorials over written guides. As video production can be
an expensive and elaborate process, this proposal is only offering an initial analysis and cost
estimates for future content projects using video. The scope of work would include:
•	 Analysis of what kind of tutorials are most needed and most suitable
•	 Search for professional training companies, content editors, and content producers
•	 Costing and timeline estimates for the different options identified
Benefits: the community will start a streamlined and managed process in the direction of video
content production.
Do-nothing option: various EOS teams are already producing video tutorials for their own audi-
ences. They will probably ask for sponsorship on a case-by-case basis.
Budget estimate: see ‘Budgets’.
10. Curated catalogue of resources
An ‘encyclopaedia of EOSIO’ would index and describe all the useful information and resourc-
es in the community, and keep it up to date as the community grows. Some topics that would
be covered are:
•	 FOSS open source projects and software libraries
•	 Books and learning materials
•	 Blogs and news within the EOS ecosystem
•	 Commercial software related to EOS blockchain
•	 Commercial service providers
Benefits: the users and developers will have a go-to resource for information.
Do-nothing option: people will keep using search engines and public chats with
unreliable results.
Budget estimate: see ‘Budgets’.
To find out why this is important, click here.
26
EOS Core+ Blue Paper
	 EOS Core+
IV. EOSIO System Evolution
I. Overview
This chapter describes further goals in developing the core system components of every
EOSIO blockchain: the node software (nodeos) and system contracts.
II. Roadmap for nodeos improvements
The following suggestions outline the development that is needed to be planned and financed.
This section outlines the work packages that are immediately doable within the timeframe of
the estimate provided.
1. Project name for EOSIO community distribution
Once the community decides to start independent development of EOSIO core software, it
needs to come up with a distinctive name for the new software distribution.
Budget estimate for forking and branding: see ‘Budgets’.
Benefits: this will lead to a clearly distinct software product that is not bound to Block.one and
public perception of past events. Also, the old struggle of distinguishing between EOS and
EOSIO will be ended.
Do-nothing option: a community of EOSIO with the same name would lead to
general confusion.
2. Setting up the development process
Nontrivial challenges need to be resolved before the community can continue with further
development of the EOSIO core protocol, such as:
•	 Setting up development teams and organising their work – there should be several inde-
pendent teams in order to avoid dependency on a single software vendor.
27
EOS Core+ Blue Paper
	 EOS Core+
•	 Building and maintaining the testing infrastructure – Block.one was spending at least $1M a
year on infrastructure costs alone.
•	 Joint financing – several EOSIO blockchains are using the software and are interested in
contributing to its development. It is not clear how this contribution could be structured, as
different projects have different available funds and resources.
•	 Hiring and training – the ecosystem is lacking engineers skilled in EOSIO development. A
structured process needs to be established for hiring the talent from outside of the eco-
system and training them in EOSIO specifics.
Budget estimate: see ‘Budgets’.
3. Redesign the Blockvault plugin
The idea behind the Blockvault plugin is to let several producer nodes run with the same block
signing key, but only one of them is allowed to broadcast a signed block. Blockvault is imple-
menting a synchronisation mechanism so that the first producer who signed a block broad-
casts it, and others discard their versions. There are a number of problems with the plugin
developed by Block.one.
A new plugin needs to be designed to address the shortcomings of the original one.
Currently, in case of a disaster, the block producers must either switch to a backup node
manually or by utilising various monitoring scripts, which leads to unpredictable outages and
service degradation.
Budget estimate: see ‘Budgets’.
Benefits: block producers will receive a fully automated solution for fault tolerance. This will
increase the overall blockchain availability and performance, and reduce operational costs.
Do-nothing option: block producers will continue operating the node in a mostly
manual fashion.
4. Features and intrinsics in plugins
Whenever a blockchain (such as WAX) needs to introduce a new intrinsic function or feature,
the core of nodeos needs to be modified. There is no possibility to add such functionality in an
add-on component without touching the core system.
28
EOS Core+ Blue Paper
	 EOS Core+
The following features need to be implemented (ordered by increasing complexity):
1.	 Plugins adding intrinsics to ‘eosvm-jit’ and ‘eosvm-interp’
2.	 Plugins adding intrinsics to ‘eosvm-oc’ (it will need some rework since the intrinsics are
sequentially indexed and in a single list; the index numbers get compiled into the cached
wasms, which are stored on disk)
3.	 Adding plugins to the database (snapshots would need a rework because the code
which does the import and export accounts for all of the tables, including how to convert
between versions)
Budget estimate: see ‘Budgets’.
Benefits: more flexibility in creating side chains with distinctive features; less expensive
software maintenance.
Do-nothing option: blockchains with their additional intrinsic functions will keep maintaining
their own branches of EOSIO in isolation and without support.
5. Build scripts for standalone cleos+keosd
Currently, the EOSIO client software (cleos and keosd) for the Linux command line is only
available as part of the whole EOSIO package. The build scripts are designed for building the
whole set of software, including nodeos and its accompanying utilities. As nodeos is only com-
patible with x86_64 architecture, it makes it difficult to use the clients on other platforms, such
as ARM.
The build scripts need to be modified in a way that allows building cleos and keosd only and
skipping the rest.
Also, installation and packaging scripts need to be adapted so that client-only software distri-
bution becomes possible.
Budget estimate: see ‘Budgets’.
Benefits: will allow a broad range of computers to integrate easily with the blockchain
(Raspberry Pi, Mac, embedded Linux platforms, and IoT hardware).
Do-nothing option: third-party scripts and client software will continue to be necessary for
non-Intel platforms.
29
EOS Core+ Blue Paper
	 EOS Core+
6. Nodeos internals documentation
Many functions of nodeos, such as data serialisation, building the Merkle trees, transaction
signing, resource management, etc., are only described in the source code. Anyone who
needs to understand how the system works at the protocol level currently has to go through
the source code.
There needs to be a set of documents describing the core protocol functionality and logic.
Also detailed documentation of libraries, like fs, ChainBase, etc.
Budget estimate: see ‘Budgets’.
Benefits: easier to attract a larger community of developers; improved software support.
Do-nothing option: source code will continue being the main source of information, which
leads to longer adoption times.
7. Fix the broken print output
In current nodeos versions, it is difficult to enable the smart contract ‘print’ output. There
needs to be a simple configuration option that enables it.
Budget estimate: see ‘Budgets’.
8. Clean up the nodeos test suite
The core EOSIO software is neutral to the system token and does not need it. It’s the system
smart contracts that define the token and its role in the blockchain. However, many unit tests
in nodeos are dependent on ‘default currency’, which is defined globally during the build time.
Also, this default currency’s precision is hardcoded in multiple places, and many tests break if
the default precision is changed. This needs a cleanup so that each test that needs a currency
defines it autonomously, and no default currency is defined at the core software level.
Budget estimate: see ‘Budgets’.
9. API endpoint for speculative transaction status
Nodeos keeps track of all transaction IDs that it has seen until they expire. In addition, the
‘node_transaction_index’ table contains information on which peers have seen the transaction.
30
EOS Core+ Blue Paper
	 EOS Core+
This data needs to be exposed via an HTTP API so that applications can keep track of their
transactions. In addition, there needs to be a way to export this information in real-time to ex-
ternal consumers (for example, via WebSocket connection).
Budget estimate: see ‘Budgets’.
III. Roadmap for EOS system contract improvements
Up to now, the EOS system contracts have been developed by Block.one, and a number of
community demands were never addressed. This section is mostly EOS-centric, as other
blockchains are maintaining their own sets of system contracts.
1. Documentation cleanup
There are many errors and inconsistencies in the system contract documentation. They need
reviewing and fixing.
Budget estimate: see ‘Budgets’.
2. Accumulating BP rewards
Currently, block producer (BP) rewards need to be claimed every 24h+0.5s, which is causing
an inconvenience and a lot of extra effort. The system contract needs to be modified to allow
for the accumulation of rewards to be claimed any time at the BP’s convenience. Telos imple-
mented this a long time ago, and Telos BPs can claim their rewards to an arbitrary schedule.
Budget estimate: see ‘Budgets’.
3. Contract pays
Application smart contracts need to be allowed to pay for their users’ transaction resources so
that users enjoy a more streamlined UX.
Budget estimate: see ‘Budgets’.
31
EOS Core+ Blue Paper
	 EOS Core+
4. Staking, REX, voting
The whole architecture of stalking, REX, and voting needs a critical review. Also, several out-
standing issues to be solved in the near term:
•	 Automatic unstaking: fix issues with unstaking that require a manual ‘refund’ action after
the unstaking period
•	 REX/voting: fix the issue that requires users to stake, so they can vote for BPs before they
can deposit into REX; the initial user experience is bad
•	 System contract: fix unstaking
Budget estimate: see ‘Budgets’.
5. Project token names in eosio.token
Currently ‘eosio.token’ contract is only serving the system token, namely EOS on the EOS
Mainnet. The proposal is to allow the contract to serve other symbol names. The names can
be auctioned, thus generating a new source of income for the blockchain. Research is needed
in order to understand the demand and security implications.
Budget estimate: see ‘Budgets’.
6. Unsellable RAM
Free accounts are often abused due to their ability to sell the excess RAM granted to them
during creation. A solution is needed where a RAM buyer would prevent the account from
selling it.
Budget estimate: see ‘Budgets’.
IV. Topics for research and design
This section outlines the work packages which require a significant design and research effort,
with unclear outcomes. Still, it is important to set long-term goals.
32
EOS Core+ Blue Paper
	 EOS Core+
1. RocksDB: undefined future
Block.one added an option to store the blockchain state in RocksDB instead of the ChainBase
backend. The initial goal was to reduce the storage I/O load and memory footprint. It resulted
in poor performance and a higher memory footprint.
A deeper analysis is needed on whether RocksDB support is bringing any benefits to deter-
mine whether it needs to be maintained in future code.
2. Native EVM plugin
Current Ethereum Virtual Machine implementation on EOSIO is deploying the EVM emulator
into a smart contract. This makes it difficult (if not impossible) to execute computationally in-
tensive operations, such as ‘bmul’.
As soon as it is possible to implement intrinsics and features in an independent plugin, a stan-
dalone EVM plugin would be a natural choice. It will enable a whole new range of applications
to be deployed on EOSIO, preserving Ethereum compatibility.
The EOS Argentina team has been selected for this task, the completion of which will provide
an essential tool needed to scale operations on the chain.
3. Getter methods in contracts
Currently, clients and contracts are reading the contract tables directly from blockchain state
memory. They also need to have the structure of secondary indexes, while it’s not exposed in
ABI. Another problem is that the current method of accessing the tables makes it difficult to
implement synchronous cross-contract calls.
Other blockchain stacks, such as Ethereum and Elrond, allow the contracts to expose get-
ter methods so that the smart contract itself reads the state memory and prepares it for
the consumer.
A deeper feasibility analysis and a development plan are needed for this feature.
33
EOS Core+ Blue Paper
	 EOS Core+
4. Advanced account permissions
Flexible account permissions are one of the strengths of EOSIO. Research should be done to
see how to make them even more powerful (expiring permissions, permission restrictions on
action data, etc.).
Several core developers in the past have expressed displeasure at having the existing account
structure fixed as part of the core protocol instead of implemented inside contracts. It led to an
ever-expanding set of potential changes, each requiring a hard fork. Investigate the possibility
of migrating the authentication system from the core to system contracts. If successful, this
could increase future flexibility.
5. Horizontal scalability
A blockchain cannot grow infinitely. As we have seen on WAX, a growing RAM footprint be-
comes challenging for infrastructure operators. Also, the intensively-growing blockchain histo-
ry is becoming difficult to process.
An end-to-end design is needed for spinning-up side chains which would offer transparency
for the end-user. They would offer resources paid in the Mainnet token and provide distinctive
features which are not available on the Mainnet. For example: a different way of usage billing;
an EVM; fast finality; fixed-price RAM, etc.
6. State memory scalability
Current EOSIO software handles the state memory in its ChainBase database, mapped to a
file in a filesystem. This works well for a footprint of up to 100GB but causes delays in spinning
up the nodes and puts higher demands on the hardware.
A design effort needs to be made to allow a much bigger state footprint, probably hundreds of
gigabytes. Possible approaches could be: store irreversible data in persistent storage and use
ChainBase for reversible data only; or design a new type of storage available to the contracts in
addition to ChainBase tables.
34
EOS Core+ Blue Paper
	 EOS Core+
7. Fast finality
In the current consensus protocol, a block becomes irreversible from about 3 minutes after it
gets signed by a block producer. Other options for the consensus need to be explored in order
to reduce the finality delay to a matter of seconds.
8. Evolution of economy and governance models
During the past 3.5 years of EOS operation (and about 10 years of global blockchain tech-
nology development) many different economy and governance models have been designed
and tested.
We have learned a number of shortcomings in the current EOS model. In addition, other
EOSIO blockchains have demonstrated the benefits and disadvantages of alternative models.
It will be beneficial for EOS Mainnet to build a working group, with the goals of developing and
proposing ways to transform the EOS governance and economy; mitigating its current disad-
vantages; and improving its position in the global market.
The work should address the following topics:
•	 Analysis of current situation and shortcomings
•	 Design of the target economy and governance models (probably with several
different options)
•	 Technical analysis (what needs to be built to implement them)
•	 Transition analysis (how do we get there)
•	 Transition roadmap (project timeline and execution plan)
Once the roadmap is defined and approved by the community and capital holders, the corre-
sponding software development and project execution need to be initiated and funded.
To find out why this is important, click here.
35
EOS Core+ Blue Paper
	 EOS Core+
V. Smart Contract Tooling Evolution
I. Overview
The goal of this chapter is to formulate the directions and strategies for future toolkits and de-
velopment environments, primarily targeting EOSIO smart contract developers.
II. Current picture
As of the end of 2021, the EOSIO smart contract development environment is quite mature,
with its own strengths and weaknesses.
So far, most of the tooling has been developed and maintained by Block.one. Several inde-
pendent tooling projects have also been developed by the community.
The contract development tools mainly support Linux systems, and many developers complain
about the lack of support for Mac and Windows. There are several different approaches, such
as running a Linux virtual machine on a Mac or Windows computer, but there is no solution that
is fully tested, maintained, and well documented.
Smart contract internals and the standard API are well documented, but there is a lack of how-
to guides, best practices, and high-level overviews of the system as a whole.
Several public testnets are maintained by different teams, and there are also guides for setting
up one’s own testnet.
1. Tools maintained by Block.one
•	 EOSIO core: nodeos, cleos, ke-
osd, several C++ libraries, and a
testing framework
•	 Contract Development Toolkit: eosio.cdt,
a C++ compiler, and a set of libraries
•	 eosjs: a Javascript library for
EOSIO clients
•	 EOSIO Web IDE: a browser-based con-
tract development environment
36
EOS Core+ Blue Paper
	 EOS Core+
2. Community tools
•	 EosLime, a unit testing framework
•	 Infeos, a unit testing framework
•	 Hydra, a smart contract testing frame-
work (closed source)
•	 EOS Studio, an EOSIO IDE
•	 Golang, smart contract SDK
•	 Rust, smart contract SDK
•	 CLSDK, an alternative to eosio.cdt
III. Gap analysis: missing pieces
We interviewed several development teams and these are the features they want for smart
contract development:
•	 Curated catalogue: open-source smart
contracts and their use cases
•	 How-to and step-by-step guides: for
particular use cases
•	 Dos and don’ts: best practice in
solving problems
•	 Security guides: for smart
contract development
•	 Libraries: typical contracts and templates
•	 Updates: especially for EOSLime
and Infeos
•	 OS Support: ARM CPU and macOS for
smart contract development (currently
only x86 Mac computers are supported)
•	 Quick Start scripts: Docker and
Kubernetes containers
•	 Smart contract vulnerability testing kit:
such as MythX for Ethereum
•	 Ricardian contracts: improved format,
multi-lingual, HTML-safe
IV. Smart contract tooling roadmap
1. Smart contract testing framework
Unit testing is an essential part of the mod-
ern software development process. It allows
quick retesting of the codebase during
the development of new features, and it
significantly improves the overall project
quality. Several tools for this purpose were
37
EOS Core+ Blue Paper
	 EOS Core+
developed by the community, but they have
not been updated for a long time due to
poor financing.
a. Unit testing with JavaScript
Writing unit tests in JavaScript is easier,
quicker, and more intuitive than in C++. Tests
written in JavaScript are also easier to un-
derstand and maintain. Moreover, blockchain
developers from Ethereum or EVM-based
networks write unit tests in JavaScript. The
possibility of using JavaScript for EOSIO
smart contracts unit tests will allow these
developers to easily migrate over and start
developing and testing on EOSIO.
b. Code coverage
Code coverage is an automated procedure
that measures the efficiency of unit tests.
Having code coverage for EOSIO smart
contracts will allow developers to understand
how effectively the unit tests assess their
code, whether there is enough testing in
place, and how to maintain test quality over
the lifecycle of a smart contract.
c. Vulnerability/security testing
As we have seen multiple times in the block-
chain industry, a tiny security bug can result
in a loss of millions of dollars if not caught
and fixed in time. This is why it is crucial for
developers to have a way to test their smart
contracts for common vulnerabilities and
security flaws during the development cycle.
d. Smart contract performance testing
Writing high-performance EOSIO smart
contracts can lower the costs both for devel-
opers and users when an action from a smart
contract is executed. Having the possibility
of testing the performance of actions within
an EOSIO smart contract will allow develop-
ers to write better, more resource-optimised
code. As smart contracts consume re-
sources, effective testing would mean fewer
resource-intensive contracts can be made.
e. Debugging EOSIO smart contracts
Often developers find issues within their
code that are hard to track down and fix due
to the impossibility of debugging their smart
contracts. This slows down the development
process. Being able to debug EOSIO smart
contracts will allow developers to quick-
ly track down bugs and better understand
the flow of an action which was written by
another developer.
Budget estimate: see ‘Budgets’.
Benefits: improvement in code quali-
ty and speed of development, easier
developer onboarding.
Do-nothing option: projects will have to con-
tinue building their own specialised tools.
38
EOS Core+ Blue Paper
	 EOS Core+
2. Contract deployment automation framework
Deploying smart contracts on the blockchain requires developers to execute a repeatable set
of steps. Often, after a smart contract is deployed, an initial set of transactions must be exe-
cuted in a specific order to set up the contract for usage. Also, each transaction status needs
to be verified, and failed transactions must be re-executed.
Having an automatic staged deployment will allow developers to build this set of steps as
code, and automatically perform the deployment and execution of the required actions
for initialisation.
Budget estimate: see ‘Budgets’.
Benefits: improvement in software quality, reduced software maintenance expenses.
Do-nothing option: projects will continue with either manual deployment or their custom
initialisation scripts.
3. Library of contracts and templates
Many projects encounter the same set of tasks, and they have to reinvent the wheel to meet
their goals. A curated library of audited and documented reference code needs to be created
and maintained. The following is an incomplete list of templates that need to be built:
•	 Staking contracts for fungible and non-fungible tokens (once a user deposits their assets,
a certain reward is calculated, and the user can participate in decision-making by voting
with their stake)
•	 Token sale contracts (implementing several popular sale schemas)
•	 Escrow models for fungible and non-fungible assets
•	 Random number generation (in a provable and secure way)
•	 Oracle contracts
Budget estimate: see ‘Budgets’.
39
EOS Core+ Blue Paper
	 EOS Core+
4. Prepackaged tools for Windows and macOS
New developers are often confronted with the problem of having no straightforward way to de-
velop EOSIO contracts on their current platforms, such as Windows or Mac. Apple has phased
out x86 CPU architecture support, and developers currently have no easy way to develop on
Apple silicon computers.
Toolsets for both platforms need to be built, consisting of the following components:
•	 Easy-to-install prepackaged container with all required tools (CDT, cleos, keosd, nodeos)
•	 Integration with popular IDEs, such as Visual Studio Code by Microsoft
•	 Scripts for quick and automated launching of local testnet
•	 Detailed installation instructions and user documentation
•	 Integration of unit testing frameworks
•	 Tools for automated contract deployment and initialisation
Budget estimate: see ‘Budgets’.
5. Ricardian contracts framework
The idea of Ricardian contracts in EOSIO was welcomed by the community in the early days
but didn’t get widespread adoption due to a number of factors.
A new design project needs to be initiated to address the following challenges:
•	 Multi-lingual support: the framework needs to allow publishing multiple translations of the
same document.
•	 HTML-safe: the new formatting standard needs to prevent coders from adding hidden
links, and it needs to be safe for any unprepared reader.
•	 New storage method: currently, Ricardian contracts are stored as part of the Application
Binary Interface (ABI), which contributes to the traffic volumes as ABIs are retrieved by API
clients frequently. Ricardian contracts may not need to be part of the ABI.
•	 Wallet support: current implementations do not provide easy means for wallets and
browsers to display Ricardian content. The document needs to be easy to display in a
user-friendly manner.
40
EOS Core+ Blue Paper
	 EOS Core+
•	 Publisher signing: it might be beneficial to use the publisher’s signature as part of the
Ricardian contract (similar to PGP signatures).
•	 Documentation: the toolkit needs to be accompanied by developer guidelines and
complete examples.
•	 Compiler standardisation: the current CDT compiler would need to be adapted to the
new standard.
Budget estimate: see ‘Budgets’.
Benefits: a new framework will open up new poswwsibilities for applications and wallets; the
smart contracts will be self-documented on the blockchain.
Do-nothing option: Ricardian contracts in their current form are rarely in use, and wallets are
not displaying them. This feature may eventually become obsolete.
6. Smart contract development kits roadmap
The Contract Development Toolkit (CDT), developed and maintained by Block.one, is a com-
plex and mature piece of software. Yet there are ways to improve it, as outlined below. It is dif-
ficult to estimate the effort needed to meet these goals, as they are mostly related to research
and design.
As several independent SDK projects are emerging, there is a need for a reference document
that would specify the standard in naming and interfaces. Different programming languages
use different paradigms for iterators and key/value tree traversal, so such a document needs
to address various patterns and approaches. The ideal goal is to help developers switch easily
between programming languages without having to learn the whole environment from scratch.
The WASM standard does not offer a common standard for debugging information. A working
group has been formed, but there is little progress. It is likely that the EOSIO core developer
community needs to establish a close collaboration with WASM CG in order to accelerate the
creation of corresponding standards.
41
EOS Core+ Blue Paper
	 EOS Core+
7. Low-code / no-code framework
There is a growing market segment that allows businesses to create new applications by uti-
lising simple blocks and a GUI that connects them and defines a workflow. We are starting to
see many low-code / no-code developers embracing this side of blockchain technology. Also
in recent years, the Scratch language has become very popular for educating children, as it
allows users to write programs by connecting simple blocks in a graphical interface. Research
is needed in order to determine whether such an approach makes sense for blockchain appli-
cation development. The following questions need to be answered:
•	 Is there a business need for such an application builder?
•	 Is it feasible within the EOSIO application paradigm?
•	 What will it cost to develop and maintain?
Budget estimate for performing the research: see ‘Budgets’.
To find out why this is important, click here.
42
EOS Core+ Blue Paper
	 EOS Core+
VI. EOSIO for Business
and Government
I. Overview
Open, permissionless, decentralised – these are the first things that might come to mind when
thinking of blockchain. For enterprises, the priorities are different. In many cases, a permis-
sioned, private chain might better serve their specific needs. Depending on the use case, a
consortium or an internal blockchain with a hashing algorithm that sends internal checkpoints
to a public network may be more valuable.
Such enterprises might also dispense with the ‘tokenomics’ and liquidity aspects of pub-
lic networks, which rely on community support to keep the blockchain validated and are not
directly influenced by the price of a chain’s native token. The value proposition of blockchain
is also variable and depends on the type of industry and use case. Why would an enterprise
use the technology? An HFS report (2019) asked more than 300 executives about their organ-
isations’ blockchain initiatives, the business impact, and the potential disruptive aspects of
the technology:
Source: HFS Research in conjunction with Wipro
43
EOS Core+ Blue Paper
	 EOS Core+
As we can see, many executives believe blockchain will be more disruptive and transformative
to business than even the internet. Leading companies are therefore likely to create new roles
and perhaps entirely new departments to migrate themselves into this new digital age.
EOSIO has a market share to capture and is uniquely positioned to out-compete the incum-
bents of the industry – Hyperledger, Corda, Hedera  Quorum. EOSIO presents a significant
advantage in its ability to perform as both a public and private solution. We see EOSIO on-
boarding both public bodies as well as enterprise customers, who have traditionally shied away
from entering the blockchain space. A steady increase of new businesses building on EOSIO
will drive value back to public chains such as the EOS Mainnet.
•	 What can we expect from competing and winning market share in enterprise blockchain?
•	 Large scale B2B and government projects
•	 Experienced developers entering the talent pool
•	 New business use cases situated between private and public
•	 An ongoing stream of highly credible positive media PR
•	 Enterprise data integrity and business value secured by EOS Mainnet
•	 The vested interest of big business in the security and governance of EOS Mainnet
•	 Corporate balance sheet investment
When EOSIO for Business launched, it created an opportunity for EOSIO to compete in this
large and rapidly expanding market. This initiative was halted by Block.one to focus on their
in-house products. There were many viable opportunities and partnerships being nurtured and
the early indications for the initiative were positive, showing that EOSIO has great potential to
penetrate the global business blockchain landscape.
44
EOS Core+ Blue Paper
	 EOS Core+
The original EOSIO for Business concept had four well-thought-out pillars:
EOSIO Premier Technical Support
—presenting companies with easily identifiable support tiers to suit their needs in out-
sourcing troubleshooting and technical assistance when launching and maintaining oper-
ations for an EOSIO implementation.
EOSIO BaaS
—an automated blockchain platform fully managed by Block.one, EOSIO BaaS (Blockchain
as a Service) allows companies to leverage blockchain technology without having to dedi-
cate internal resources to ongoing maintenance.
EOSIO Consulting
—offers direct access for EOSIO engineers to identify, architect, and implement client
blockchain solutions, including the design and implementation of EOSIO smart contracts.
EOSIO Training and Certification
—comprehensive courses covering the foundations of EOSIO, smart contract program-
ming, application development, and best practices for secure integration.
Documentation of previous offers is stored in this folder.
45
EOS Core+ Blue Paper
	 EOS Core+
Instead of directly replicating these pillars through some centrally-funded entity, we would
prefer to foster an ecosystem that would encourage anyone to launch and service a new EOS
business customer.
A small group of accomplished enterprise EOSIO implementers has already come together
out of necessity to form eos.business, focusing on three areas: EOSIO Consulting, Premier
Technical support, and Training  Certification.
The pillar most in need of transformation is EOSIO BaaS (Blockchain as a Service). A single
organisation providing BaaS does not align with the principles of our industry. We see a dis-
tributed network of companies providing an open suite of tools that allows anyone to configure
and run their own BaaS infrastructure.
For the business ecosystem to succeed, these four pillars need to be well supported by the
ENF (EOS Network Foundation) through the WP+ working groups – Core+, API+, Audit+, and
Wallet+. We recommend the ENF focus on building an enterprise-friendly suite of tools, which
supports all EOSIO implementers. This model enables our community to deliver products and
services that can capture a significant share of the enterprise blockchain market, bring new
people to the ecosystem, and drive value back to the community and EOS Mainnet.
Image by EOSIO
46
EOS Core+ Blue Paper
	 EOS Core+
II. Suite of tools
Enterprise  Government customers expect their solutions to come with a full set of tools. We
see the need for a series of enterprise-focused tools, starting with a Blockchain Configurator,
which supports blockchain setup and implementation through to day two operations.
The primary tools exist in five main areas:
•	 Setup: to easily install and deploy the EOS blockchain
•	 Block explorer: white-labelled to allow transparent inspection of the blockchain state
•	 Wallet solution: to identify users on the blockchain
•	 Search tool: to search throughout the blockchain for data
•	 Developer environment: to curate well-maintained documentation, libraries, APIs, etc.
Enterprise customers will require an additional tool suite consisting of:
•	 Blockchain Configurator
•	 Enterprise Signing Portal
•	 Enterprise focused private chains
(white-labelled block explorer)
•	 Enterprise friendly Hyperion / Dfuse solu-
tion (History API)
•	 Enterprise Developers toolkit
The Enterprise Customers tool suite will have these features:
•	 Platform architecture management
•	 Modularised, preconfigured networks
and infrastructure
•	 Easy setup and workflow
•	 Repeatability and scalability
•	 Middleware for app development
•	 Monitoring and alerting services
•	 Dashboard to view and analyse
chain code
•	 Auditable transaction records and history
•	 Built-in connections to needed services
•	 Professional consultation services
47
EOS Core+ Blue Paper
	 EOS Core+
III. Premier Technical Support
The enterprise market demands highly available platforms with Premier Technical Support.
Uninterrupted operations, fast response times, and problem resolution are essential to avoid
negative business impacts.
The customer value proposition is a reduction of risk, optimised Operating Expenses (OPEX),
prevention of outages, improved network performance, and Operations and Maintenance
(OM) efficiency.
This pillar consists of a few components:
•	 Technical Support service: product in-
stallation, configuration, or operations
•	 Troubleshooting service: case han-
dling provided as per service level
agreement (SLA)
•	 Software Update support: bug fix-
es packaged and delivered at
regular intervals
•	 Preventive Maintenance: ensures
the system runs optimally and
without interruptions
•	 Emergency Support: 24x7x365,
as required
•	 Tiered SLA packages: bronze / silver /
gold
Image by Rewired.one
48
EOS Core+ Blue Paper
	 EOS Core+
How can the ENF help?
The ENF aims to lay the foundations for groups like eos.business to come together and launch
Premier services for the EOS business ecosystem.
Foundational requirements:
•	 Clear and stable Roadmap
•	 An open and well-documented EOS codebase
•	 Quality documentation, training, and education portals
•	 Training and certification programs
IV. Blockchain as a Service (BaaS)
Enterprise and government are rapidly moving to everything as a service. The popularity of the
service-based delivery model means blockchains are a prime candidate for third-party deliv-
ery. Take, for example, the AWS Managed Blockchain initiative. The global BaaS market size in
2019 was $1.9B and is expected to grow to $24.9B by 2027. Other research predicts a market
size of $94.2B by 2026; in either case, the growth is enormous!
EOSIO should have providers offering subscription-based enterprise-grade BaaS solutions
where customers receive a myriad of support services and benefits. By building the proper
tools (see Blockchain Configurator under Tools), we can enable multiple vendors to become
BaaS providers.
1. Consulting
Professional services are a vital pillar in this ecosystem, and currently, no centrally coor-
dinated blockchain knowledge hub fulfils this condition. Enterprise customers thinking of
selecting EOSIO as their blockchain technology will be looking for a consulting network
with strategic blockchain knowledge  expertise, roadmaps, architecture, design, and
implementation capabilities.
Recently several EOSIO business implementers came together following Block.one’s decision
to drop the EOSIO for Business initiative and commenced work on eos.business to fill the void.
49
EOS Core+ Blue Paper
	 EOS Core+
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English
Eos Core+ Blue Paper - English

Contenu connexe

Similaire à Eos Core+ Blue Paper - English

An Overview of buildingSMART
An Overview of buildingSMARTAn Overview of buildingSMART
An Overview of buildingSMARTMariela Daskalova
 
OpenChain Webinar #5: Software Heritage
OpenChain Webinar #5: Software HeritageOpenChain Webinar #5: Software Heritage
OpenChain Webinar #5: Software HeritageShane Coughlan
 
Blockchain for Business
Blockchain for BusinessBlockchain for Business
Blockchain for BusinessAhmad Gohar
 
Developing for Industrial IoT with Linux OS on DragonBoard™ 410c: Session 1
Developing for Industrial IoT with Linux OS on DragonBoard™ 410c: Session 1Developing for Industrial IoT with Linux OS on DragonBoard™ 410c: Session 1
Developing for Industrial IoT with Linux OS on DragonBoard™ 410c: Session 1Qualcomm Developer Network
 
Great Open Source Compliance For Everyone (Version 3)
Great Open Source Compliance For Everyone (Version 3)Great Open Source Compliance For Everyone (Version 3)
Great Open Source Compliance For Everyone (Version 3)Shane Coughlan
 
Student Management System
Student Management SystemStudent Management System
Student Management SystemAmit Gandhi
 
Circuit 2015 Keynote - Carsten Ziegeler
Circuit 2015 Keynote -  Carsten ZiegelerCircuit 2015 Keynote -  Carsten Ziegeler
Circuit 2015 Keynote - Carsten ZiegelerICF CIRCUIT
 
eZ Systems Product Workshop Slides
eZ Systems Product Workshop SlideseZ Systems Product Workshop Slides
eZ Systems Product Workshop SlidesLinda Martin
 
Product workshop slides
Product workshop slidesProduct workshop slides
Product workshop slidesLinda Martin
 
22323006 embedded-c-tutorial-8051
22323006 embedded-c-tutorial-805122323006 embedded-c-tutorial-8051
22323006 embedded-c-tutorial-8051PRADEEP
 
19199406 embedded-c-tutorial-8051
19199406 embedded-c-tutorial-805119199406 embedded-c-tutorial-8051
19199406 embedded-c-tutorial-8051PRADEEP
 
SharePoint Wiki Feasibility Report (Draft) - Travis Barker.pdf
SharePoint Wiki Feasibility Report (Draft) - Travis Barker.pdfSharePoint Wiki Feasibility Report (Draft) - Travis Barker.pdf
SharePoint Wiki Feasibility Report (Draft) - Travis Barker.pdfInnovate Vancouver
 
ISO 15926 series standard and its business value
ISO 15926 series standard and its business valueISO 15926 series standard and its business value
ISO 15926 series standard and its business valueHiroshi Okada
 
Emerging Trends in Net-Centric Operations
Emerging Trends in Net-Centric OperationsEmerging Trends in Net-Centric Operations
Emerging Trends in Net-Centric OperationsBob Marcus
 
Top 20 Cloud Computing Companies 2014
Top 20 Cloud Computing Companies 2014Top 20 Cloud Computing Companies 2014
Top 20 Cloud Computing Companies 2014Visiongain
 
[Oracle Webcast] Discover the Oracle Blockchain Platform through the eyes of ...
[Oracle Webcast] Discover the Oracle Blockchain Platform through the eyes of ...[Oracle Webcast] Discover the Oracle Blockchain Platform through the eyes of ...
[Oracle Webcast] Discover the Oracle Blockchain Platform through the eyes of ...Sanae BEKKAR
 

Similaire à Eos Core+ Blue Paper - English (20)

An Overview of buildingSMART
An Overview of buildingSMARTAn Overview of buildingSMART
An Overview of buildingSMART
 
OpenChain Webinar #5: Software Heritage
OpenChain Webinar #5: Software HeritageOpenChain Webinar #5: Software Heritage
OpenChain Webinar #5: Software Heritage
 
Blockchain for Business
Blockchain for BusinessBlockchain for Business
Blockchain for Business
 
Developing for Industrial IoT with Linux OS on DragonBoard™ 410c: Session 1
Developing for Industrial IoT with Linux OS on DragonBoard™ 410c: Session 1Developing for Industrial IoT with Linux OS on DragonBoard™ 410c: Session 1
Developing for Industrial IoT with Linux OS on DragonBoard™ 410c: Session 1
 
Great Open Source Compliance For Everyone (Version 3)
Great Open Source Compliance For Everyone (Version 3)Great Open Source Compliance For Everyone (Version 3)
Great Open Source Compliance For Everyone (Version 3)
 
Student Management System
Student Management SystemStudent Management System
Student Management System
 
Circuit 2015 Keynote - Carsten Ziegeler
Circuit 2015 Keynote -  Carsten ZiegelerCircuit 2015 Keynote -  Carsten Ziegeler
Circuit 2015 Keynote - Carsten Ziegeler
 
eZ Systems Product Workshop Slides
eZ Systems Product Workshop SlideseZ Systems Product Workshop Slides
eZ Systems Product Workshop Slides
 
Product workshop slides
Product workshop slidesProduct workshop slides
Product workshop slides
 
Io t solutions world congress 2018 review deel 2 Gertjan van het Hof Conclus...
Io t solutions world congress 2018 review deel 2  Gertjan van het Hof Conclus...Io t solutions world congress 2018 review deel 2  Gertjan van het Hof Conclus...
Io t solutions world congress 2018 review deel 2 Gertjan van het Hof Conclus...
 
22323006 embedded-c-tutorial-8051
22323006 embedded-c-tutorial-805122323006 embedded-c-tutorial-8051
22323006 embedded-c-tutorial-8051
 
19199406 embedded-c-tutorial-8051
19199406 embedded-c-tutorial-805119199406 embedded-c-tutorial-8051
19199406 embedded-c-tutorial-8051
 
WIPO Blockchain Whitepaper
WIPO Blockchain WhitepaperWIPO Blockchain Whitepaper
WIPO Blockchain Whitepaper
 
SharePoint Wiki Feasibility Report (Draft) - Travis Barker.pdf
SharePoint Wiki Feasibility Report (Draft) - Travis Barker.pdfSharePoint Wiki Feasibility Report (Draft) - Travis Barker.pdf
SharePoint Wiki Feasibility Report (Draft) - Travis Barker.pdf
 
ISO 15926 series standard and its business value
ISO 15926 series standard and its business valueISO 15926 series standard and its business value
ISO 15926 series standard and its business value
 
Emerging Trends in Net-Centric Operations
Emerging Trends in Net-Centric OperationsEmerging Trends in Net-Centric Operations
Emerging Trends in Net-Centric Operations
 
4ire labs presentation 2019
4ire labs presentation 20194ire labs presentation 2019
4ire labs presentation 2019
 
Top 20 Cloud Computing Companies 2014
Top 20 Cloud Computing Companies 2014Top 20 Cloud Computing Companies 2014
Top 20 Cloud Computing Companies 2014
 
SIMPLE ISO 19650 TEMPLATES (BILT VIRTUAL PRESENTATION)
SIMPLE ISO 19650 TEMPLATES (BILT VIRTUAL PRESENTATION)SIMPLE ISO 19650 TEMPLATES (BILT VIRTUAL PRESENTATION)
SIMPLE ISO 19650 TEMPLATES (BILT VIRTUAL PRESENTATION)
 
[Oracle Webcast] Discover the Oracle Blockchain Platform through the eyes of ...
[Oracle Webcast] Discover the Oracle Blockchain Platform through the eyes of ...[Oracle Webcast] Discover the Oracle Blockchain Platform through the eyes of ...
[Oracle Webcast] Discover the Oracle Blockchain Platform through the eyes of ...
 

Plus de ZackGall1

ENF Q1 Report
ENF Q1 ReportENF Q1 Report
ENF Q1 ReportZackGall1
 
Audit+ Blue Paper (Chinese)
Audit+ Blue Paper (Chinese)Audit+ Blue Paper (Chinese)
Audit+ Blue Paper (Chinese)ZackGall1
 
Audit+ Blue Paper (Korean)
Audit+ Blue Paper (Korean)Audit+ Blue Paper (Korean)
Audit+ Blue Paper (Korean)ZackGall1
 
ENF Q4 2021 Quarterly Report - Chinese
ENF Q4 2021 Quarterly Report - ChineseENF Q4 2021 Quarterly Report - Chinese
ENF Q4 2021 Quarterly Report - ChineseZackGall1
 
ENF Q4 2021 Quarterly Report - English
ENF Q4 2021 Quarterly Report - EnglishENF Q4 2021 Quarterly Report - English
ENF Q4 2021 Quarterly Report - EnglishZackGall1
 
ENF Q4 2021 Quarterly Report - Korean
ENF Q4 2021 Quarterly Report - KoreanENF Q4 2021 Quarterly Report - Korean
ENF Q4 2021 Quarterly Report - KoreanZackGall1
 

Plus de ZackGall1 (6)

ENF Q1 Report
ENF Q1 ReportENF Q1 Report
ENF Q1 Report
 
Audit+ Blue Paper (Chinese)
Audit+ Blue Paper (Chinese)Audit+ Blue Paper (Chinese)
Audit+ Blue Paper (Chinese)
 
Audit+ Blue Paper (Korean)
Audit+ Blue Paper (Korean)Audit+ Blue Paper (Korean)
Audit+ Blue Paper (Korean)
 
ENF Q4 2021 Quarterly Report - Chinese
ENF Q4 2021 Quarterly Report - ChineseENF Q4 2021 Quarterly Report - Chinese
ENF Q4 2021 Quarterly Report - Chinese
 
ENF Q4 2021 Quarterly Report - English
ENF Q4 2021 Quarterly Report - EnglishENF Q4 2021 Quarterly Report - English
ENF Q4 2021 Quarterly Report - English
 
ENF Q4 2021 Quarterly Report - Korean
ENF Q4 2021 Quarterly Report - KoreanENF Q4 2021 Quarterly Report - Korean
ENF Q4 2021 Quarterly Report - Korean
 

Dernier

IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfAijun Zhang
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationIES VE
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsSafe Software
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureEric D. Schabell
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Brian Pichman
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Will Schroeder
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-pyJamie (Taka) Wang
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UbiTrack UK
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDELiveplex
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URLRuncy Oommen
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 

Dernier (20)

IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdf
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability Adventure
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-py
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URL
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 

Eos Core+ Blue Paper - English

  • 2. Table of Contents Table of Contents��������������������������������������������������������1 I. Introduction�������������������������������������������������������������������3 I. Overview ���������������������������������������������������������������������������������������3 II. Team ���������������������������������������������������������������������������������������������4 III. Phases �����������������������������������������������������������������������������������������4 1. Launchpad�������������������������������������������������������������������������������4 2. Lift-Off�������������������������������������������������������������������������������������5 3. Propel���������������������������������������������������������������������������������������6 IV. Additional considerations ����������������������������������������������������7 1. Education����������������������������������������������������������������������������������7 2. Business���������������������������������������������������������������������������������8 3. RD�������������������������������������������������������������������������������������������9 V. Summary �������������������������������������������������������������������������������������9 II. Evaluation of the Current EOS Ecosystem�������������������������������������������������������������������������10 I. Overview �������������������������������������������������������������������������������������10 II. Required developer guidelines identified by the community �������������������������������������������������������������������������������������10 1. Why EOSIO blockchain?���������������������������������������������������10 2. Real-life use cases �������������������������������������������������������������10 3. Role-specific developer guidelines �������������������������������11 III. Required EOSIO protocol information identified by the community ��������������������������������������������������������������������������������������12 1. Ricardian contracts ��������������������������������������������������������������12 2. Nodeos internal documentation������������������������������������13 3. Plugins Solutions and Examples configuration ��������13 IV. Conclusion ��������������������������������������������������������������������������������14 III. EOSIO Infosphere Evolution ��������������14 I. Overview ��������������������������������������������������������������������������������������14 II. Audience analysis ��������������������������������������������������������������������15 III. Current state of documentation ��������������������������������������� 18 1. Developers.eos.io��������������������������������������������������������������� 18 2. Docs.telos.net��������������������������������������������������������������������� 18 3. Developer.wax.io ��������������������������������������������������������������� 18 4. Blogs��������������������������������������������������������������������������������������� 18 5. GitHub ����������������������������������������������������������������������������������� 18 6. Books��������������������������������������������������������������������������������������19 7. Documentation for enterprise����������������������������������������19 IV. Learning challenges ������������������������������������������������������������ 20 V. Infosphere development proposals ������������������������������ 20 1. Information coordination group (editors-in-chief)�� 20 2. Content management platform������������������������������������21 3. End-user documentation and tutorials ���������������������22 4. High-level articles for managers���������������������������������22 5. Back-end software architecture guides �������������������23 6. Front-end software architecture guides�������������������24 7. Reference documentation �����������������������������������������������24 8. System administration guides���������������������������������������25 9. Video tutorials���������������������������������������������������������������������26 10. Curated catalogue of resources���������������������������������26 IV. EOSIO System Evolution�����������������������27 I. Overview �������������������������������������������������������������������������������������27 II. Roadmap for nodeos improvements �����������������������������27 1 EOS Core+ Blue Paper EOS Core+
  • 3. 1. Project name for EOSIO community distribution ���27 2. Setting up the development process�������������������������27 3. Redesign the Blockvault plugin������������������������������������ 28 4. Features and intrinsics in plugins�������������������������������� 28 5. Build scripts for standalone cleos+keosd�����������������29 6. Nodeos internals documentation ������������������������������30 7. Fix the broken print output����������������������������������������������30 8. Clean up the nodeos test suite������������������������������������30 9. API endpoint for speculative transaction status���� 30 III. Roadmap for EOS system contract improvements ��31 1. Documentation cleanup����������������������������������������������������31 2. Accumulating BP rewards������������������������������������������������31 3. Contract pays������������������������������������������������������������������������31 4. Staking, REX, voting���������������������������������������������������������32 5. Project token names in eosio.token ���������������������������32 6. Unsellable RAM�����������������������������������������������������������������32 IV. Topics for research and design ���������������������������������������32 1. RocksDB: undefined future���������������������������������������������33 2. Native EVM plugin�������������������������������������������������������������33 3. Getter methods in contracts�����������������������������������������33 4. Advanced account permissions���������������������������������� 34 5. Horizontal scalability�������������������������������������������������������� 34 6. State memory scalability������������������������������������������������ 34 7. Fast finality�����������������������������������������������������������������������������35 8. Evolution of economy and governance models�����35 V. Smart Contract Tooling Evolution36 I. Overview ������������������������������������������������������������������������������������ 36 II. Current picture ������������������������������������������������������������������������ 36 1. Tools maintained by Block.one������������������������������������� 36 2. Community tools ���������������������������������������������������������������37 III. Gap analysis: missing pieces �������������������������������������������37 IV. Smart contract tooling roadmap �������������������������������������37 1. Smart contract testing framework �������������������������������37 2. Contract deployment automation framework�������� 39 3. Library of contracts and templates���������������������������� 39 4. Prepackaged tools for Windows and macOS��������40 5. Ricardian contracts framework������������������������������������40 6. Smart contract development kits roadmap��������������41 7. Low-code / no-code framework�����������������������������������42 VI. EOSIO for Business and Government�������������������������������������������������������������������� 43 I. Overview ������������������������������������������������������������������������������������ 43 II. Suite of tools �����������������������������������������������������������������������������47 III. Premier Technical Support ����������������������������������������������48 IV. Blockchain as a Service (BaaS) �������������������������������������� 49 1. Consulting���������������������������������������������������������������������������� 49 2. Training and certification��������������������������������������������������51 3. Generic enterprise needs�����������������������������������������������52 4. Miscellaneous���������������������������������������������������������������������52 5. Business+�����������������������������������������������������������������������������52 V. EOSIO for Business RD proposals ������������������������������ 53 1. Enterprise signing portal �������������������������������������������������� 53 2. Blockchain configurator��������������������������������������������������54 3. Block explorer�������������������������������������������������������������������� 55 4. History API �������������������������������������������������������������������������� 55 5. Enterprise developer toolkit������������������������������������������ 55 VI. Conclusion ����������������������������������������������������������������������������� 56 VII. Future Tech Research and Development �����������������������������������������������������������������57 I. Overview �������������������������������������������������������������������������������������57 II. Self-sovereign identity for EOSIO �������������������������������������57 1. Legacy digital identity: the problems�������������������������� 58 2. Self-sovereign identity: the solution�������������������������� 59 VIII. Enabling SSI on EOSIO �����������������������62 I. Overview �������������������������������������������������������������������������������������62 1. EOSIO DID specs���������������������������������������������������������������62 2. W3C verifiable conditions�����������������������������������������������62 IX. EOS Legal Support��������������������������������������64 I. Stage one: knowledge and referral database ��������������64 1. Overview��������������������������������������������������������������������������������64 2. Fields of interest���������������������������������������������������������������� 65 3. Delivery ���������������������������������������������������������������������������������� 65 4. Budget estimates�������������������������������������������������������������� 66 II. Stage two: establishing international principles ���������67 1. Overview���������������������������������������������������������������������������������67 2. Practical use�������������������������������������������������������������������������67 3. Delivery �����������������������������������������������������������������������������������67 4. Budget estimates�������������������������������������������������������������� 68 X. Index���������������������������������������������������������������������������������� 69 2 EOS Core+ Blue Paper EOS Core+
  • 4. I. Introduction I. Overview This document presents a series of recommendations for the improvement of the EOSIO blockchain protocol. It forms part of a larger proposal developed by ‘Core+’, a working group commissioned by the EOS Network Foundation (ENF) to identify existing gaps in the frame- work and creative routes to expand its offerings. It has been conducted alongside a number of other ENF-commissioned working groups, each targeting a distinct area of EOSIO. A multitude of causes created voids in the support for and visibility of EOS and EOSIO net- works. The role of Block.one, who have historically been responsible for the resources to sup- port the uptake of EOSIO, has diminished in the ecosystem. This requires new resources to be developed and disseminated. Particular attention must be given to the onboarding, learning, and tools that are needed to empower developers, system admins, IT and software architects, and infrastructure and support engineers. The proposal has been structured in such a way as to accommodate different audiences. We did not want to submit a 200-page document to the community, but also did not want to throw away any of the valuable information and research conducted by our partner network. As a result, the proposal is divided into three: • A one-pager describing the essence of Core+ • The main blue paper (this document) • Supporting documentation which will be presented in GitBook for further reading The centre of the proposal is the recommendation of a three-phase plan. Supported by the information detailed in the chapters below, our goal is for the community and ENF to be able to make an informed decision on the best way forward for EOSIO. 3 EOS Core+ Blue Paper EOS Core+
  • 5. II. Team A diverse team makes up the Core+ working group. Zaisan, who leads the group, was founded by EOS Amsterdam, EOS Dublin, Cryptolions, and EOS Barcelona. It is made up of seasoned professionals with diverse skill sets, including senior developers, infrastructure administrators, project managers, cybersecurity, and legal experts. It brings together some of the most senior minds in the EOSIO ecosystem and decades of collective experience in Big Four consulting and project management. Zaisan has a footprint across six countries in Europe, with a global partner network that has been instrumental to the research. Zaisan has been supported in this research by EOS Costa Rica, CTIC, Eurecat, EOS Bulgaria, and Rewired.one, and all of the other community contributors who helped along this journey. They selected this set of teams because of their unique position in the market. Each has expe- rience with EOS development and also hands-on experience delivering EOSIO-based projects to startups, SMEs, MNCs, and universities. For more information on the contributing team see here. III. Phases Using the analogy of a space shuttle, we have named the three phases for the development of EOSIO ‘Launchpad’, ‘Lift-Off’, and ‘Propel’. 1. Launchpad Before anything else, the entire EOSIO craft needs to be stabilised on a ‘Launchpad’ and pointed in the right direction. If not, it will take off on the wrong path. Launchpad involves a comprehensive review and update of the currently available docu- mentation and training for EOSIO. These have been neglected for years and must become community-owned and managed in order to provide a stable base to build upon. This is the minimum required to produce value for the network, filling the major technical gaps identified by Zaisan, Rewired.one, EOS Costa Rica, CTIC, TestingSaaS, Eurecat, the individuals interviewed, and the other community collaborators. 4 EOS Core+ Blue Paper EOS Core+
  • 6. The Launchpad phase is a necessary prerequisite in order to start any of the other initia- tives in ‘Lift-Off’ and ‘Propel’. Current and up-to-date information is needed first, then an audit for what is missing and should be prioritised. Budget estimate: see ‘Budgets’. 2. Lift-Off Once the craft is securely on the Launchpad, it needs to be prepared for ‘Lift-Off’. The team needs to ensure that all of the modules are in place to give the best possible chance of a successful voyage. The focus here is the community: multi-chain compatibility, global collaborations, frame- works for incentives, and enhanced onboarding (partnerships, events, working groups, etc.). A key aspect of this package is the addition of business-focused solutions. Another is the addition of comprehensive templates for easy deployment of applications and tools on the chain. Guides and templates are needed for new blockchain implementations such as DeFi 3.0 and GameFi. On the social and onboarding side, Lift-Off will include a framework for attracting as many new developers, community members, and business partners as possible. This will take the form of high-quality videos, incentives, and high-profile research pieces. Lift-Off will incorporate regional representatives to ensure that it is relevant to global communities (some use cases in China may not be as applicable in the Netherlands). It is essential to make sure that we provide support for non-English speaking communities. Valuable partnerships with appealing companies, IT analyst firms, and institutions will contribute to the presence and visibility of EOSIO. We will build on the previous options by targeting educational institutions to get EOS / EOSIO included in Computer Science de- partments around the world. Zaisan, Costa Rica, and Rewired all have university connec- tions and can quickly open these lines of communication to empower the next generation of EOS rockstar developers. Lift-Off will also incorporate a legal framework that can help projects get past the POC stage and into a live environment. Budget estimate: see ‘Budgets’. 5 EOS Core+ Blue Paper EOS Core+
  • 7. 3. Propel After Lift-Off, there needs to be the correct fuel required to ‘Propel’ the craft to the re- quired destination. Propel includes all of the above with augmented features — the focus becomes speed and scale, supporting many millions of new users and communities from around the world. The task Propel addresses is how EOS can be brought to the major business and pop- ulation centres of the world—Europe, India, East Asia, and the Americas. However, each region has different customs, laws, and business practices. Within Propel we will need to establish ‘boots on the ground’ within these locations with specific tools and use cases per region. Examples of areas that will need addressing include: • General Data Protection Regulation (GDPR) • California Consumer Privacy Act (CPA) • Financial Action Task Force (FATF) • India Stack • Persons Information Protection Law The CCID Research Institute of the Ministry of Industry and Information Technology of China publishes the Global Public Chain Technology Evaluation Index. According to their rankings, EOS is the best blockchain, ranked for basic/tech, applicability, and creativity. This promises a wider and easier acceptance of EOSIO-based products and solutions in China. The Propel phase will have a dedicated RD team who are constantly maintaining and updating the codebase to keep EOS / EOSIO competitive and a player on the global block- chain stage. Budget estimate: see ‘Budgets’. 6 EOS Core+ Blue Paper EOS Core+
  • 8. IV. Additional considerations There are certain aspects that we feel are required but there are also areas that we feel should be considered as they will greatly increase the reach, userbase, usability, and legal frameworks required for EOS / EOSIO to perform in the global blockchain market once again. These can be broken down into: 1. Education 45,000 ‘students’ began courses through the Block.one educational funnel. However, this did not result in any significant growth in the number of EOSIO developers or community members. Nonetheless, it demonstrated that there is a huge demand for education in the blockchain space, but there need to be clear next steps and a support network for people who are interested. As such, we need to consider what support there is to bring students to a level where they are actively participating and contributing to the success of the network. We believe this should be trialled as time-based training where a student joins with a class for a term and there is a clear way to build connections and networks. These could either be delivered as EOSIO communi- ty-led courses or in partnership with existing universities. Educational modules could be segmented according to the target audience, for example: Executives - One-pagers, infographics, videos Developers - Comprehensive step-by-step guides (written form), multilin- gual support / documentation, forums, and groups (Discord, Telegram) Infrastructure Administrators - Debugging guides (video and text), script templates, sample infrastructure set-ups 7 EOS Core+ Blue Paper EOS Core+
  • 9. Zaisan, Costa Rica, CTIC and Rewired.one all have university connections and can quickly open these lines of communication to empower the next generation of EOS rockstar developers. 2. Business Adoption by startups, SMEs, and MNCs is instrumental to the success of any chain. For busi- nesses to enter a certain blockchain there are minimum requirements that must be met from compliance, legal, performance, and operational perspectives. This would include such indus- try use cases as: Technical integrations with high-profile enterprise stacks. APIs and connectors to rapidly implement EOSIO solutions to SAP, Oracle, Microsoft, CISCO Other integrations, support, and documentation for IoT, RFID, Identity solutions (DID, VC, IDM) Use case templates to allow quick deployment of POCs and use cases without com- plex architecture—here we will pay special attention to upcoming ‘hype’ GameFi use case (rewards, incentives, promotion, recommendations, Play2Earn, leaderboards) NFT use cases (invoices, materials passports, collectables, rewards, tickets) DeFi use cases (borrowing, lending, staking, trading) 8 EOS Core+ Blue Paper EOS Core+
  • 10. 3. RD A dedicated team is needed to continue researching bleeding-edge technology and working on how to integrate that with the current ecosystem. These are areas such as IoT, decentral- ised identity, VR solutions, scaling solutions, decentralised storage, and other fields that need further research. The RD team should take a ‘partner first’ approach to make sure that best- in-class technology exists. Valuable partnerships with well-known companies and institutions will contribute to the presence and visibility of EOSIO. If there are no partnership opportunities available, then the team can look at research, development, and architecture ‘in-house’. V. Summary What is central to this entire proposal is an outline and a list of suggestions for what needs to be done in order to give EOS / EOSIO the competitive advantage it once had. The chapters below provide the supporting detail and evidence for the recommendations made. For further supporting information and the full extent of research that accompanied this Blue Paper, see our GitBook page. To find out why this is important, click here. 9 EOS Core+ Blue Paper EOS Core+
  • 11. II. Evaluation of the Current EOS Ecosystem I. Overview There currently exist gaps in the information and support for EOSIO. Such gaps are liable to cause problems for developers, and in the worst cases could result in problems for the end-user due to poor implementation of the protocol. The goal of this chapter is to assess the current state of EOS from the perspec- tive of new users and developers, identifying gaps to be closed. II. Required developer guidelines identified by the community 1. Why EOSIO blockchain? Different protocols with powerful character- istics fit different necessities. Not all of them are recommended and none can solve every problem. To avoid mistakes in decision mak- ing we need to provide clear documentation to help tech lead developers to guide their companies to the right course without having to become instant experts. The two basic questions are: 1. Why seek a solution in blockchain? 2. What protocol is most likely to fix the problem? It is very important that the documentation is not only oriented for developers but also for non-techy decision-makers across different fields to help them to decide if integrating an EOSIO private or public blockchain network would help their company. 2. Real-life use cases When speaking of blockchain, people might think about security, trust, transparency, integrity, and most of all immutability. But all these do not necessarily apply to all use cases, it all depends on each specific sce- nario. Solutions can be forced to solve prob- lems, however, that isn’t the best idea with a blockchain. Exposing and explaining real-world applica- tions could help developers and interested 10 EOS Core+ Blue Paper EOS Core+
  • 12. people to make better decisions about whether to use this technology or not. Even better, if blockchain technology is used, to apply it taking advantage of all of the nice features of EOSIO. For example, one could use the multi-sig feature that restricts ac- tions to be executed only with the consent of all the responsible parties specified in the permissions. Real-world examples are the best way to introduce EOSIO tools, technologies, and configurations to improve the understanding of the general public and decision-makers. Most guides explain how to do a task but fail to explain why or what are the best scenari- os that could fit that necessity, and when to implement these. 3. Role-specific developer guidelines Software development is divided into vari- ous phases, each one of them is focused on specific rules to achieve the best final prod- uct but those rules need to be placed some- where, to allow coding professionals to get into the right spot without having to dive too deep, constantly reinventing the wheel. a. Front-end Applying best practices helps contributors to understand the code easily and thus speed up the improvement and integration process for any tools. It also helps new developers to learn how to do things right without resort- ing to empirical learning already covered by others in the past. Specifying the options for building front-end projects with suggested architecture, tech- nologies, security principles, wallet integra- tions, and many others will definitely make any front-end developer’s life much easier, while at the same time resulting in a more complete final product. b. Back-end Back-end development is like the chef in a restaurant, without whom there is not much to do for the front-end. If the chef in the kitchen is working for another restau- rant too, this could produce unavailability of food and service, causing the front-end to lose customers. This metaphor exemplifies what happens if a wrong design is applied. It is easy to un- derstand why it is really important to have clear guidance on the steps, phases, and any other helpful things that might improve the process of correct software development in terms of design, architecture, libraries, protocols, security, and any other important criteria that are applicable. c. DevOps and CI/CD In a developer team, there could be between 2 and 5 members working on the same project and applying new integrations. Some other developers could be there just for performance improvement, others for design changes, and so on. It could be very expen- sive to pay someone to only keep manually updating all the changes that are integrated 11 EOS Core+ Blue Paper EOS Core+
  • 13. into a repository. It is necessary to correctly set up DevOps tools that help the team’s overall productivity, reduce project cost, and help to better shape the production process via more accurate and continuous feedback. Specifically for EOSIO, using a real example, a project could contain many services that need to be updated with any minor change that happens, for example, an update to the wallet, the back-end, the front-end, or any other service that a project could be using. All of those updates will be very costly in terms of time if DevOps along with CI/CD is not applied correctly. d. Setting up a developer environment Each project could have a different develop- er environment depending on the use case, but a core of base tools may be useful in all instances. For example: What are the recommended IDEs for C++ developers? Which C++ smart contract compiler is best to fit a given use case? What is the best blockchain environment to test the smart contract? It won’t make any difference in the logic but some people could notice that certain pl- ugins, blockchain environments, and others bring better compatibility, productivity, ease of understanding, and so on. Correct guid- ance could improve team performance. III. Required EOSIO protocol information identified by the community 1. Ricardian contracts The following gaps in the implementation of Ricardian contracts have been identified by the community: a. Multi-lingual Ricardian contracts The following suggestions would strengthen the Ricardian Contract to spread to a general adoption by the community. b. HTML-safe Ricardian contracts The framework needs to allow the pub- lishing of multiple translations of the same document. c. Wallet support and user-friendly display Current implementations do not provide easy means for wallets and browsers to display the Ricardian content. The doc- ument needs to be easy to display in a user-friendly manner. 12 EOS Core+ Blue Paper EOS Core+
  • 14. d. Signatures on Ricardian contracts It might be beneficial to use the publish- er’s signature as part of the Ricardian contract (similar to PGP signatures). In general, a Ricardian contract is a hu- man-readable document that comes togeth- er with a smart contract and describes its expected behaviour. It may also serve as a legal agreement, although the details of legal applicability have not been explored. Developers often publish their Ricardian contracts, as is normal in blockchain, to maintain transparency. However, since there is no clear standard to follow there is some variation in developer implementation. The fact this is open to individual interpretation results in discrepancies that could cause tools to malfunction. Providing Ricardian Contract examples following a standard will help to remove any openness of interpretation and will leave only one way to do things, so all types of content will have the same underlying architecture. 2. Nodeos internal documentation The following gaps have been identified in the nodeos internal documentation: • Data serialisation • Building the Merkle trees • Transaction signing • Resource management • Core protocol functionality • Core protocol logic • Accumulating block producer rewards • State history solutions The nodeos component is modular and provides a set of nodeos plugins to configure a node according to specific needs. Knowing how to do a certain configuration or the best place to put a node in a network is difficult, there is not much documentation on how to configure a producing node, peering node, chain API node with its extension, or a State History API. 3. Plugins Solutions and Examples configuration The nodeos component is modular and provides a set of nodeos plugins to configure a node according to specific needs. Knowing how to do a certain configuration or the best place to put a node in a network is difficult, there is not much documentation on how to configure a producing node, peering node, chain API node with its extension, or a State History API. 13 EOS Core+ Blue Paper EOS Core+
  • 15. III. EOSIO Infosphere Evolution I. Overview This chapter outlines various streams of information related to the EOSIO blockchain ecosys- tem and suggests ways to build and deliver this information to its consumers. Many different teams will work on creating and organising the content. This chapter aims to provide general guidelines to writers and engineers and to suggest a possible structure. Owners and C-level executives Software developers Technical leads, IT archi- tects, software architects Infrastructure and support engineers IV. Conclusion The need for deeper support of EOSIO devel- opers is clear, and there is potential to capture new users by clarifying and advertising the unique features and benefits of the EOSIO protocol. Many business, administration, and governmental requirements would be ideally solved with EOSIO, but not if those organisa- tions are unaware of EOSIO’s suitability, or if their developers are put off by the lack of doc- umentation. The detailed information provided by the existing community in identifying these shortcomings is invaluable in the process of overcoming them. To find out why this is important, click here. 14 EOS Core+ Blue Paper EOS Core+
  • 16. II. Audience analysis Information consumers can be categorised in a number of different ways. Knowing the type of consumer will help us to organise and deliver the information in an optimal way to help the decision-makers understand the benefits of EOS and make the right choices. Decision Makers: Each decision-maker will have their own level of expertise and experience with EOSIO blockchains: Each level of reader is typically looking for different kinds of information. Newbies will need: • Articles and videos explaining the bigger picture (how it all works, what it does, what the major components are) Intermediate Already in EOSIO projects, looking for a reference in a specific topic. Newbie Zero experience with EOSIO, probably some knowledge about Ethereum and Bitcoin. They first need to understand how it all works in a general way. Expert Top-level EOS partners able to edit, review and add more content. 15 EOS Core+ Blue Paper EOS Core+
  • 17. • Quick-start tutorials for architects and developers about typical applications and basic tasks • High-level overviews of infrastructure components for infrastructure engineers (their com- munication, system requirements) Intermediates with some knowledge of EOS will need: • Guidelines and examples (how to complete basic tasks, system guidelines) • Software references (APIs, libraries, further quickstarts, guides) Different readers prefer different presentation formats. Managers and decision-makers like seeing pitch decks with detailed diagrams. Newbies may prefer video tutorials, whereas inter- mediates want more detail in the form of text. Newbies, intermediates, experts – anyone unfamiliar with EOS will need: • Straightforward ‘how-to’ guides for onboarding, using the blockchain, buying tokens, and wallet security • Easy ways to find suitable blockchain applications (dApps) and smart contracts • Links to videos and social media campaigns to raise awareness and fuel new ideas Business decision-makers will also want to know the business benefits – they will need: • Executive summaries, views of high-level architecture • Typical real-life use cases with actual examples • Success stories, real-life business cases, do’s and don’ts • Information about any available service providers, infrastructure providers, as well as de- velopment teams, integration, consulting, and training companies within EOS • Information about other existing public blockchains and their distinctive features System and software architects who define the development strategy need to have: 16 EOS Core+ Blue Paper EOS Core+
  • 18. • High-level overviews and tutorials on EOSIO technology • A full catalogue of FOSS and commercial software and tools Software developers who deal with hands-on coding and software design will want to see deep dives into the technology itself, including: • Tutorials and guides for smart contracts, middleware, front-end • Explanation of the bigger picture (system components, infrastructure, and APIs) • Reference documentation for APIs and SDKs • Catalogue of EOSIO open-source libraries and tools • Catalogue of open-source projects built on EOSIO System administrators responsible for planning and maintaining all the infrastructure that runs the blockchain nodes will need to know about: Covered Missing ✓ Introduction (general overview, basic terminology) ✓ ‘Getting started’ guide ✓ Guides on smart contracts (protocols, permissions) ✓ Test network startup guide ✓ Tutorials for gaming (Tic-tac-toe and Elemental Battles) ✓ Manuals (nodeos and utilities, SDK, API references) ✓ Resources (links to community groups, tools, and public blockchains) ✗ No real-life use cases or examples ✗ No ‘why’ (newbies are not told why each tutorial is needed, what their goal is, what they should learn, or what they will be able to move on to next) ✗ Outdated information in some guides ✗ Missing details and dependencies in development environment installation guides ✗ Lack of explanation of local test blockchain vs. public blockchain ✗ No help for Windows or macOS users (guides and tutorials are aimed at Linux users) ✗ Too little information for front-end developers 17 EOS Core+ Blue Paper EOS Core+
  • 19. • Infrastructure planning and capacity management • Software installation and configuration guides III. Current state of documentation Information is currently scattered across six independent information sources, making it sometimes tricky to find answers to particular topics, with some not covered at all. 1. Developers.eos.io The EOSIO Developer Portal holds a large collection of the available EOSIO documentation. The following table outlines the topics covered and the gaps where topics are missing. 2. Docs.telos.net Provides general information about various components of Telos public blockchain, such as EVM (Ethereum Virtual Machine), account creation, staking, etc. 3. Developer.wax.io Explains components specific to the WAX public blockchain, such as the web wallet and RNG. Some outdated guides describe services that will soon be unsupported. Minimal references to EOS, mainly about how to deploy EOS dApps on WAX. 4. Blogs There are active EOS community members posting useful articles on various technical topics related to EOS and WAX. 5. GitHub A code hosting platform for collaboration on open-source projects at different levels of code maturity and documentation. There is no comprehensive catalogue of EOS-related projects or of EOS. 18 EOS Core+ Blue Paper EOS Core+
  • 20. 6. Books ‘Learn EOS Development’ by Christoph Michel - a detailed guide for any developer who wants to start with EOSIO smart contracts. 7. Documentation for enterprise When enterprises consider a technology, they have a business problem that needs a solution. They ask themselves: ‘Do we need a blockchain, or is a traditional database management system sufficient to support our use case?’ We need clear examples and selection tools/flow charts to help businesses assess the pros and cons of blockchain technology. Once the decision to implement blockchain is made, the case for EOSIO needs to be made. This is a straightforward sales story, driven by comparisons with competing blockchain solu- tions, highlighting the flexibility, scalability, and security that only EOSIO can deliver. This should also include such issues as running costs and, most crucially, environmental impact linked to corporate social responsibility. A single sign-on (SSO) platform, such as Microsoft Active Directory (MAD), is typically de- ployed in an enterprise environment, storing user login credentials centrally. Once a user authenticates, they have smooth access to all corporate platforms and applications. To provide a similar SSO experience when introducing blockchain, we need to offer a pass- wordless implementation of EOSIO, which can be provided by WebauthN, using either hard- ware keys or biometrics for authentication. We need to supply clear documentation, combined with use cases and demos, highlighting the ease of implementation. WebauthN is a significant competitive differentiator for the EOSIO software ecosystem and may attract new users with a security and compliance mindset. A typical use case for enterprise customers is in long-term data retention policies that pro- tect against or provide evidence for potential lawsuits. Furthermore, an enterprise must demonstrate high levels of integrity to meet regulatory, audit, or compliance obligations. Implementing a private blockchain within the customer environment with a hashing towards the EOSIO public Mainnet demonstrates and secures the integrity of a chain of events. Re- ordering or forking a private chain is easily identifiable. Anyone with access to both networks can compare check-point data and determine the exact time the action occurred. This pro- cess turns a hybrid blockchain solution into a tamper-evident system. The solution needs to be clearly described, with a value proposition and accompanied by practical implementation guides. 19 EOS Core+ Blue Paper EOS Core+
  • 21. How can the ENF help? • Provide industry-specific views of how EOSIO can solve problems for a variety of use cas- es (apart from four different case studies, there are no enterprise use-cases) • Create a competitive analysis of how EOSIO compares to other blockchains for deploy- ment, running costs, performance, environmental impact, etc. • Improve the documentation of WTMsig, which helps block-producing nodes enjoy a safe and secure highly available setup for block production • Create specific documentation for high availability setups, which is key for enterprise operations • Provide documentation and guidance on which smart contract state storage to use in a given scenario (ChainBase or RocksDB) IV. Learning challenges In summary, everyone is missing the bigger picture. Tutorials that explain the EOS logic and other disparate information are all scattered across different forms of media without useful best practice guides, real-life use cases, and concrete examples. This creates levels of frus- tration and developers often have to go onto chats to find out what they need to know. V. Infosphere development proposals We recommend the community and EOS Network Foundation allocate the funds to address these challenges. 1. Information coordination group (editors-in-chief) The first step is to form a group to coordinate and maintain the overall information struc- ture. Subsequently, it can assign tasks to content creators and manage the information reference platform. Benefits: information will be managed, organised, and easy to find for every kind of reader. 20 EOS Core+ Blue Paper EOS Core+
  • 22. Do-nothing option: information sources will continue to be incomplete, unmanaged, and devel- opers and business customers will be less inclined to adopt EOSIO. Budget estimate: see ‘Budgets’. 2. Content management platform The next step will be to create a platform to help users navigate existing documenta- tion and find links to the best sources. The following criteria need to be met in the content management system: • Long-term support • Easy collaboration between content writers • WYSIWYG editing for graphics and clear presentation • Changes to tracking and document control • Flexible permissions (a chief editor delegates rights to other authors) • A navigation structure to help viewers find information as quickly as possible • Ability to address different readers with direct links to subcategories • No duplication of information (to define and structure this is a nontrivial task) • Long-term ownership definition (DNS, hosting, content management) • A reliable hosting solution (preferably backed by GitHub) A long-term plan for developers.eos.io is needed: Pre-requisites: the team of editors-in-chief needs to be formed and budgeted for. Benefits: a consistently reliable place for aggregation and indexing of various EOS information resources, and a publishing platform for content creators. Option 1 Block.one keeps maintaining the content, and we link to it; ENF and Block.one coordinate their efforts in content creation Option 2 ENF takes over the website and content ownership 21 EOS Core+ Blue Paper EOS Core+
  • 23. Do-nothing option: the EOS community will rely on various third-party content host- ing solutions and EOSIO will continue to suffer from increasingly incomplete and disparate documentation. Budget estimate: see ‘Budgets’. 3. End-user documentation and tutorials All blockchain users need guides and tutorials for simple daily tasks, such as: Benefits: easier onboarding of non-technical and non-crypto-savvy users. Do-nothing option: community forced to rely on self-organisation via forums and chats, with a limited number of enthusiast groups creating the content beyond the EOS strategic vision. Budget estimate: see ‘Budgets’. 4. High-level articles for managers Business and technical management need comprehensive top-down ways to present the EOS technology to C-level executives and decision-makers, covering the following topics: • Blockchain operation: accounts, smart contracts, resources, permissions Navigation of end-user wallet software: a catalogue of key managers, account manag- ers, basic token transfers, etc. (focusing on all platforms, not just Linux) Catalogue of end-user applications: blogs, informational websites, news Explanation of Resources: CPU, NET, RAM and their management Onboarding: keys and accounts creation, basic security 22 EOS Core+ Blue Paper EOS Core+
  • 24. • Blockchain infrastructure explanation: roles of different kinds of nodes, operational chal- lenges, in house-skills required • Blockchain applications: architecture, components, and communication • Typical blockchain business use cases • Overview of existing complete products and key functions (i.e. Upland, Emanate, DeFi projects, etc.) • Private vs. public blockchain: decision-helping guide showing budgets and costs • Legal aspects: privacy, finances, custodianship, taxation • Answering a government RFP: key points, references, how-tos Benefits: executive and senior technical managers, as well as end-users and developers, will be better informed about the EOS blockchain and its possibilities. Do-nothing option: several consultancy groups are already in operation, and they present the technology to their customers. This would continue as a local business initiative, however, without support, they may gradually disappear. Budget estimate: see ‘Budgets’. 5. Back-end software architecture guides We need to fill the gaps in its current EOSIO technical documentation. New developers are faced with a set of reference documents and a few disconnected articles, but nothing that would explain the general logic of blockchain operation. This lack of documentation often leads to bad design decisions, security breaches, and loss of money for users. The following topics need to be covered: • Blockchain applicability: where EOSIO fits the job and where it does not • Smart contracts: basic design principles, do’s and don’ts • Smart contract security guide: known threats and ways to mitigate them • Back-end architecture guide: infrastructure, APIs, server-side security, scalability, etc. • Sending and receiving payments: finality, forks, inline actions for transactions • How-to and best practice: explaining typical usage patterns 23 EOS Core+ Blue Paper EOS Core+
  • 25. • Setting up the development environment: (IDE, etc.) Windows, Mac • Reference projects: quickstarts, templates • Troubleshooting guides: testing, debugging Benefits: engineers will avoid common mistakes, their products will be brought to market with quicker turnarounds, and quality control will be improved. Do-nothing option: engineers will keep asking the same questions in development chats, and will keep making mistakes that will throw their projects back, or open up security holes. Budget estimate: see ‘Budgets’. 6. Front-end software architecture guides Web and mobile application engineers need development and architecture guides. This area of front-end development is very dynamic, so this has to be an ongoing effort. The following guides are needed: • User security: types of wallets and key management • Resource management: how to keep RAM, NET, and CPU costs down • Web application: frameworks and libraries • Mobile application: frameworks and libraries Benefits: developers will stop wasting time in community chats, and start delivering optimal solutions that are cheaper to maintain and update. Do-nothing option: application developers will continue to make common mistakes as a result of using outdated libraries, tutorials, and insecure methods of handling users. Budget estimate: see ‘Budgets’. 7. Reference documentation So far most of the reference documentation has been maintained by Block.one. Should that change, the community will need to keep the documentation up to date as an essential ele- ment of any software development environment. This part of the proposal covers the refer- ence documentation for the following topics: 24 EOS Core+ Blue Paper EOS Core+
  • 26. • Smart contract API • Nodeos API • Wallet APIs • Other service APIs (such as Hyperion) • Client libraries • Third-party extensions for the EOS node software (nodeos) Benefits: developers get complete and up-to-date documentation for their work. Do-nothing option: the reference documentation will become increasingly outdated and obso- lete, and the overall development quality will degrade. Budget estimate: see ‘Budgets’. 8. System administration guides Currently, whenever a new team needs to set up their EOSIO server infrastructure, they start from scratch, fail, then order in bigger hardware and ask for advice within the community. System administrators need help to plan and operate their environment. Topics to be covered: • Hardware planning and sizing • System setup scenarios and options • Block producer guidelines • Redundancy and fault tolerance • Troubleshooting the blockchain nodes, emergency failures, and recovery Benefits: overall blockchain stability and performance will improve, minimising unnecessary costs and time loss. Do-nothing option: system engineers will keep struggling to bring up their blockchain nodes and will keep making common mistakes. It may potentially lead to application or core blockchain degradation. Budget estimate: see ‘Budgets’. 25 EOS Core+ Blue Paper EOS Core+
  • 27. 9. Video tutorials Many people say they prefer video tutorials over written guides. As video production can be an expensive and elaborate process, this proposal is only offering an initial analysis and cost estimates for future content projects using video. The scope of work would include: • Analysis of what kind of tutorials are most needed and most suitable • Search for professional training companies, content editors, and content producers • Costing and timeline estimates for the different options identified Benefits: the community will start a streamlined and managed process in the direction of video content production. Do-nothing option: various EOS teams are already producing video tutorials for their own audi- ences. They will probably ask for sponsorship on a case-by-case basis. Budget estimate: see ‘Budgets’. 10. Curated catalogue of resources An ‘encyclopaedia of EOSIO’ would index and describe all the useful information and resourc- es in the community, and keep it up to date as the community grows. Some topics that would be covered are: • FOSS open source projects and software libraries • Books and learning materials • Blogs and news within the EOS ecosystem • Commercial software related to EOS blockchain • Commercial service providers Benefits: the users and developers will have a go-to resource for information. Do-nothing option: people will keep using search engines and public chats with unreliable results. Budget estimate: see ‘Budgets’. To find out why this is important, click here. 26 EOS Core+ Blue Paper EOS Core+
  • 28. IV. EOSIO System Evolution I. Overview This chapter describes further goals in developing the core system components of every EOSIO blockchain: the node software (nodeos) and system contracts. II. Roadmap for nodeos improvements The following suggestions outline the development that is needed to be planned and financed. This section outlines the work packages that are immediately doable within the timeframe of the estimate provided. 1. Project name for EOSIO community distribution Once the community decides to start independent development of EOSIO core software, it needs to come up with a distinctive name for the new software distribution. Budget estimate for forking and branding: see ‘Budgets’. Benefits: this will lead to a clearly distinct software product that is not bound to Block.one and public perception of past events. Also, the old struggle of distinguishing between EOS and EOSIO will be ended. Do-nothing option: a community of EOSIO with the same name would lead to general confusion. 2. Setting up the development process Nontrivial challenges need to be resolved before the community can continue with further development of the EOSIO core protocol, such as: • Setting up development teams and organising their work – there should be several inde- pendent teams in order to avoid dependency on a single software vendor. 27 EOS Core+ Blue Paper EOS Core+
  • 29. • Building and maintaining the testing infrastructure – Block.one was spending at least $1M a year on infrastructure costs alone. • Joint financing – several EOSIO blockchains are using the software and are interested in contributing to its development. It is not clear how this contribution could be structured, as different projects have different available funds and resources. • Hiring and training – the ecosystem is lacking engineers skilled in EOSIO development. A structured process needs to be established for hiring the talent from outside of the eco- system and training them in EOSIO specifics. Budget estimate: see ‘Budgets’. 3. Redesign the Blockvault plugin The idea behind the Blockvault plugin is to let several producer nodes run with the same block signing key, but only one of them is allowed to broadcast a signed block. Blockvault is imple- menting a synchronisation mechanism so that the first producer who signed a block broad- casts it, and others discard their versions. There are a number of problems with the plugin developed by Block.one. A new plugin needs to be designed to address the shortcomings of the original one. Currently, in case of a disaster, the block producers must either switch to a backup node manually or by utilising various monitoring scripts, which leads to unpredictable outages and service degradation. Budget estimate: see ‘Budgets’. Benefits: block producers will receive a fully automated solution for fault tolerance. This will increase the overall blockchain availability and performance, and reduce operational costs. Do-nothing option: block producers will continue operating the node in a mostly manual fashion. 4. Features and intrinsics in plugins Whenever a blockchain (such as WAX) needs to introduce a new intrinsic function or feature, the core of nodeos needs to be modified. There is no possibility to add such functionality in an add-on component without touching the core system. 28 EOS Core+ Blue Paper EOS Core+
  • 30. The following features need to be implemented (ordered by increasing complexity): 1. Plugins adding intrinsics to ‘eosvm-jit’ and ‘eosvm-interp’ 2. Plugins adding intrinsics to ‘eosvm-oc’ (it will need some rework since the intrinsics are sequentially indexed and in a single list; the index numbers get compiled into the cached wasms, which are stored on disk) 3. Adding plugins to the database (snapshots would need a rework because the code which does the import and export accounts for all of the tables, including how to convert between versions) Budget estimate: see ‘Budgets’. Benefits: more flexibility in creating side chains with distinctive features; less expensive software maintenance. Do-nothing option: blockchains with their additional intrinsic functions will keep maintaining their own branches of EOSIO in isolation and without support. 5. Build scripts for standalone cleos+keosd Currently, the EOSIO client software (cleos and keosd) for the Linux command line is only available as part of the whole EOSIO package. The build scripts are designed for building the whole set of software, including nodeos and its accompanying utilities. As nodeos is only com- patible with x86_64 architecture, it makes it difficult to use the clients on other platforms, such as ARM. The build scripts need to be modified in a way that allows building cleos and keosd only and skipping the rest. Also, installation and packaging scripts need to be adapted so that client-only software distri- bution becomes possible. Budget estimate: see ‘Budgets’. Benefits: will allow a broad range of computers to integrate easily with the blockchain (Raspberry Pi, Mac, embedded Linux platforms, and IoT hardware). Do-nothing option: third-party scripts and client software will continue to be necessary for non-Intel platforms. 29 EOS Core+ Blue Paper EOS Core+
  • 31. 6. Nodeos internals documentation Many functions of nodeos, such as data serialisation, building the Merkle trees, transaction signing, resource management, etc., are only described in the source code. Anyone who needs to understand how the system works at the protocol level currently has to go through the source code. There needs to be a set of documents describing the core protocol functionality and logic. Also detailed documentation of libraries, like fs, ChainBase, etc. Budget estimate: see ‘Budgets’. Benefits: easier to attract a larger community of developers; improved software support. Do-nothing option: source code will continue being the main source of information, which leads to longer adoption times. 7. Fix the broken print output In current nodeos versions, it is difficult to enable the smart contract ‘print’ output. There needs to be a simple configuration option that enables it. Budget estimate: see ‘Budgets’. 8. Clean up the nodeos test suite The core EOSIO software is neutral to the system token and does not need it. It’s the system smart contracts that define the token and its role in the blockchain. However, many unit tests in nodeos are dependent on ‘default currency’, which is defined globally during the build time. Also, this default currency’s precision is hardcoded in multiple places, and many tests break if the default precision is changed. This needs a cleanup so that each test that needs a currency defines it autonomously, and no default currency is defined at the core software level. Budget estimate: see ‘Budgets’. 9. API endpoint for speculative transaction status Nodeos keeps track of all transaction IDs that it has seen until they expire. In addition, the ‘node_transaction_index’ table contains information on which peers have seen the transaction. 30 EOS Core+ Blue Paper EOS Core+
  • 32. This data needs to be exposed via an HTTP API so that applications can keep track of their transactions. In addition, there needs to be a way to export this information in real-time to ex- ternal consumers (for example, via WebSocket connection). Budget estimate: see ‘Budgets’. III. Roadmap for EOS system contract improvements Up to now, the EOS system contracts have been developed by Block.one, and a number of community demands were never addressed. This section is mostly EOS-centric, as other blockchains are maintaining their own sets of system contracts. 1. Documentation cleanup There are many errors and inconsistencies in the system contract documentation. They need reviewing and fixing. Budget estimate: see ‘Budgets’. 2. Accumulating BP rewards Currently, block producer (BP) rewards need to be claimed every 24h+0.5s, which is causing an inconvenience and a lot of extra effort. The system contract needs to be modified to allow for the accumulation of rewards to be claimed any time at the BP’s convenience. Telos imple- mented this a long time ago, and Telos BPs can claim their rewards to an arbitrary schedule. Budget estimate: see ‘Budgets’. 3. Contract pays Application smart contracts need to be allowed to pay for their users’ transaction resources so that users enjoy a more streamlined UX. Budget estimate: see ‘Budgets’. 31 EOS Core+ Blue Paper EOS Core+
  • 33. 4. Staking, REX, voting The whole architecture of stalking, REX, and voting needs a critical review. Also, several out- standing issues to be solved in the near term: • Automatic unstaking: fix issues with unstaking that require a manual ‘refund’ action after the unstaking period • REX/voting: fix the issue that requires users to stake, so they can vote for BPs before they can deposit into REX; the initial user experience is bad • System contract: fix unstaking Budget estimate: see ‘Budgets’. 5. Project token names in eosio.token Currently ‘eosio.token’ contract is only serving the system token, namely EOS on the EOS Mainnet. The proposal is to allow the contract to serve other symbol names. The names can be auctioned, thus generating a new source of income for the blockchain. Research is needed in order to understand the demand and security implications. Budget estimate: see ‘Budgets’. 6. Unsellable RAM Free accounts are often abused due to their ability to sell the excess RAM granted to them during creation. A solution is needed where a RAM buyer would prevent the account from selling it. Budget estimate: see ‘Budgets’. IV. Topics for research and design This section outlines the work packages which require a significant design and research effort, with unclear outcomes. Still, it is important to set long-term goals. 32 EOS Core+ Blue Paper EOS Core+
  • 34. 1. RocksDB: undefined future Block.one added an option to store the blockchain state in RocksDB instead of the ChainBase backend. The initial goal was to reduce the storage I/O load and memory footprint. It resulted in poor performance and a higher memory footprint. A deeper analysis is needed on whether RocksDB support is bringing any benefits to deter- mine whether it needs to be maintained in future code. 2. Native EVM plugin Current Ethereum Virtual Machine implementation on EOSIO is deploying the EVM emulator into a smart contract. This makes it difficult (if not impossible) to execute computationally in- tensive operations, such as ‘bmul’. As soon as it is possible to implement intrinsics and features in an independent plugin, a stan- dalone EVM plugin would be a natural choice. It will enable a whole new range of applications to be deployed on EOSIO, preserving Ethereum compatibility. The EOS Argentina team has been selected for this task, the completion of which will provide an essential tool needed to scale operations on the chain. 3. Getter methods in contracts Currently, clients and contracts are reading the contract tables directly from blockchain state memory. They also need to have the structure of secondary indexes, while it’s not exposed in ABI. Another problem is that the current method of accessing the tables makes it difficult to implement synchronous cross-contract calls. Other blockchain stacks, such as Ethereum and Elrond, allow the contracts to expose get- ter methods so that the smart contract itself reads the state memory and prepares it for the consumer. A deeper feasibility analysis and a development plan are needed for this feature. 33 EOS Core+ Blue Paper EOS Core+
  • 35. 4. Advanced account permissions Flexible account permissions are one of the strengths of EOSIO. Research should be done to see how to make them even more powerful (expiring permissions, permission restrictions on action data, etc.). Several core developers in the past have expressed displeasure at having the existing account structure fixed as part of the core protocol instead of implemented inside contracts. It led to an ever-expanding set of potential changes, each requiring a hard fork. Investigate the possibility of migrating the authentication system from the core to system contracts. If successful, this could increase future flexibility. 5. Horizontal scalability A blockchain cannot grow infinitely. As we have seen on WAX, a growing RAM footprint be- comes challenging for infrastructure operators. Also, the intensively-growing blockchain histo- ry is becoming difficult to process. An end-to-end design is needed for spinning-up side chains which would offer transparency for the end-user. They would offer resources paid in the Mainnet token and provide distinctive features which are not available on the Mainnet. For example: a different way of usage billing; an EVM; fast finality; fixed-price RAM, etc. 6. State memory scalability Current EOSIO software handles the state memory in its ChainBase database, mapped to a file in a filesystem. This works well for a footprint of up to 100GB but causes delays in spinning up the nodes and puts higher demands on the hardware. A design effort needs to be made to allow a much bigger state footprint, probably hundreds of gigabytes. Possible approaches could be: store irreversible data in persistent storage and use ChainBase for reversible data only; or design a new type of storage available to the contracts in addition to ChainBase tables. 34 EOS Core+ Blue Paper EOS Core+
  • 36. 7. Fast finality In the current consensus protocol, a block becomes irreversible from about 3 minutes after it gets signed by a block producer. Other options for the consensus need to be explored in order to reduce the finality delay to a matter of seconds. 8. Evolution of economy and governance models During the past 3.5 years of EOS operation (and about 10 years of global blockchain tech- nology development) many different economy and governance models have been designed and tested. We have learned a number of shortcomings in the current EOS model. In addition, other EOSIO blockchains have demonstrated the benefits and disadvantages of alternative models. It will be beneficial for EOS Mainnet to build a working group, with the goals of developing and proposing ways to transform the EOS governance and economy; mitigating its current disad- vantages; and improving its position in the global market. The work should address the following topics: • Analysis of current situation and shortcomings • Design of the target economy and governance models (probably with several different options) • Technical analysis (what needs to be built to implement them) • Transition analysis (how do we get there) • Transition roadmap (project timeline and execution plan) Once the roadmap is defined and approved by the community and capital holders, the corre- sponding software development and project execution need to be initiated and funded. To find out why this is important, click here. 35 EOS Core+ Blue Paper EOS Core+
  • 37. V. Smart Contract Tooling Evolution I. Overview The goal of this chapter is to formulate the directions and strategies for future toolkits and de- velopment environments, primarily targeting EOSIO smart contract developers. II. Current picture As of the end of 2021, the EOSIO smart contract development environment is quite mature, with its own strengths and weaknesses. So far, most of the tooling has been developed and maintained by Block.one. Several inde- pendent tooling projects have also been developed by the community. The contract development tools mainly support Linux systems, and many developers complain about the lack of support for Mac and Windows. There are several different approaches, such as running a Linux virtual machine on a Mac or Windows computer, but there is no solution that is fully tested, maintained, and well documented. Smart contract internals and the standard API are well documented, but there is a lack of how- to guides, best practices, and high-level overviews of the system as a whole. Several public testnets are maintained by different teams, and there are also guides for setting up one’s own testnet. 1. Tools maintained by Block.one • EOSIO core: nodeos, cleos, ke- osd, several C++ libraries, and a testing framework • Contract Development Toolkit: eosio.cdt, a C++ compiler, and a set of libraries • eosjs: a Javascript library for EOSIO clients • EOSIO Web IDE: a browser-based con- tract development environment 36 EOS Core+ Blue Paper EOS Core+
  • 38. 2. Community tools • EosLime, a unit testing framework • Infeos, a unit testing framework • Hydra, a smart contract testing frame- work (closed source) • EOS Studio, an EOSIO IDE • Golang, smart contract SDK • Rust, smart contract SDK • CLSDK, an alternative to eosio.cdt III. Gap analysis: missing pieces We interviewed several development teams and these are the features they want for smart contract development: • Curated catalogue: open-source smart contracts and their use cases • How-to and step-by-step guides: for particular use cases • Dos and don’ts: best practice in solving problems • Security guides: for smart contract development • Libraries: typical contracts and templates • Updates: especially for EOSLime and Infeos • OS Support: ARM CPU and macOS for smart contract development (currently only x86 Mac computers are supported) • Quick Start scripts: Docker and Kubernetes containers • Smart contract vulnerability testing kit: such as MythX for Ethereum • Ricardian contracts: improved format, multi-lingual, HTML-safe IV. Smart contract tooling roadmap 1. Smart contract testing framework Unit testing is an essential part of the mod- ern software development process. It allows quick retesting of the codebase during the development of new features, and it significantly improves the overall project quality. Several tools for this purpose were 37 EOS Core+ Blue Paper EOS Core+
  • 39. developed by the community, but they have not been updated for a long time due to poor financing. a. Unit testing with JavaScript Writing unit tests in JavaScript is easier, quicker, and more intuitive than in C++. Tests written in JavaScript are also easier to un- derstand and maintain. Moreover, blockchain developers from Ethereum or EVM-based networks write unit tests in JavaScript. The possibility of using JavaScript for EOSIO smart contracts unit tests will allow these developers to easily migrate over and start developing and testing on EOSIO. b. Code coverage Code coverage is an automated procedure that measures the efficiency of unit tests. Having code coverage for EOSIO smart contracts will allow developers to understand how effectively the unit tests assess their code, whether there is enough testing in place, and how to maintain test quality over the lifecycle of a smart contract. c. Vulnerability/security testing As we have seen multiple times in the block- chain industry, a tiny security bug can result in a loss of millions of dollars if not caught and fixed in time. This is why it is crucial for developers to have a way to test their smart contracts for common vulnerabilities and security flaws during the development cycle. d. Smart contract performance testing Writing high-performance EOSIO smart contracts can lower the costs both for devel- opers and users when an action from a smart contract is executed. Having the possibility of testing the performance of actions within an EOSIO smart contract will allow develop- ers to write better, more resource-optimised code. As smart contracts consume re- sources, effective testing would mean fewer resource-intensive contracts can be made. e. Debugging EOSIO smart contracts Often developers find issues within their code that are hard to track down and fix due to the impossibility of debugging their smart contracts. This slows down the development process. Being able to debug EOSIO smart contracts will allow developers to quick- ly track down bugs and better understand the flow of an action which was written by another developer. Budget estimate: see ‘Budgets’. Benefits: improvement in code quali- ty and speed of development, easier developer onboarding. Do-nothing option: projects will have to con- tinue building their own specialised tools. 38 EOS Core+ Blue Paper EOS Core+
  • 40. 2. Contract deployment automation framework Deploying smart contracts on the blockchain requires developers to execute a repeatable set of steps. Often, after a smart contract is deployed, an initial set of transactions must be exe- cuted in a specific order to set up the contract for usage. Also, each transaction status needs to be verified, and failed transactions must be re-executed. Having an automatic staged deployment will allow developers to build this set of steps as code, and automatically perform the deployment and execution of the required actions for initialisation. Budget estimate: see ‘Budgets’. Benefits: improvement in software quality, reduced software maintenance expenses. Do-nothing option: projects will continue with either manual deployment or their custom initialisation scripts. 3. Library of contracts and templates Many projects encounter the same set of tasks, and they have to reinvent the wheel to meet their goals. A curated library of audited and documented reference code needs to be created and maintained. The following is an incomplete list of templates that need to be built: • Staking contracts for fungible and non-fungible tokens (once a user deposits their assets, a certain reward is calculated, and the user can participate in decision-making by voting with their stake) • Token sale contracts (implementing several popular sale schemas) • Escrow models for fungible and non-fungible assets • Random number generation (in a provable and secure way) • Oracle contracts Budget estimate: see ‘Budgets’. 39 EOS Core+ Blue Paper EOS Core+
  • 41. 4. Prepackaged tools for Windows and macOS New developers are often confronted with the problem of having no straightforward way to de- velop EOSIO contracts on their current platforms, such as Windows or Mac. Apple has phased out x86 CPU architecture support, and developers currently have no easy way to develop on Apple silicon computers. Toolsets for both platforms need to be built, consisting of the following components: • Easy-to-install prepackaged container with all required tools (CDT, cleos, keosd, nodeos) • Integration with popular IDEs, such as Visual Studio Code by Microsoft • Scripts for quick and automated launching of local testnet • Detailed installation instructions and user documentation • Integration of unit testing frameworks • Tools for automated contract deployment and initialisation Budget estimate: see ‘Budgets’. 5. Ricardian contracts framework The idea of Ricardian contracts in EOSIO was welcomed by the community in the early days but didn’t get widespread adoption due to a number of factors. A new design project needs to be initiated to address the following challenges: • Multi-lingual support: the framework needs to allow publishing multiple translations of the same document. • HTML-safe: the new formatting standard needs to prevent coders from adding hidden links, and it needs to be safe for any unprepared reader. • New storage method: currently, Ricardian contracts are stored as part of the Application Binary Interface (ABI), which contributes to the traffic volumes as ABIs are retrieved by API clients frequently. Ricardian contracts may not need to be part of the ABI. • Wallet support: current implementations do not provide easy means for wallets and browsers to display Ricardian content. The document needs to be easy to display in a user-friendly manner. 40 EOS Core+ Blue Paper EOS Core+
  • 42. • Publisher signing: it might be beneficial to use the publisher’s signature as part of the Ricardian contract (similar to PGP signatures). • Documentation: the toolkit needs to be accompanied by developer guidelines and complete examples. • Compiler standardisation: the current CDT compiler would need to be adapted to the new standard. Budget estimate: see ‘Budgets’. Benefits: a new framework will open up new poswwsibilities for applications and wallets; the smart contracts will be self-documented on the blockchain. Do-nothing option: Ricardian contracts in their current form are rarely in use, and wallets are not displaying them. This feature may eventually become obsolete. 6. Smart contract development kits roadmap The Contract Development Toolkit (CDT), developed and maintained by Block.one, is a com- plex and mature piece of software. Yet there are ways to improve it, as outlined below. It is dif- ficult to estimate the effort needed to meet these goals, as they are mostly related to research and design. As several independent SDK projects are emerging, there is a need for a reference document that would specify the standard in naming and interfaces. Different programming languages use different paradigms for iterators and key/value tree traversal, so such a document needs to address various patterns and approaches. The ideal goal is to help developers switch easily between programming languages without having to learn the whole environment from scratch. The WASM standard does not offer a common standard for debugging information. A working group has been formed, but there is little progress. It is likely that the EOSIO core developer community needs to establish a close collaboration with WASM CG in order to accelerate the creation of corresponding standards. 41 EOS Core+ Blue Paper EOS Core+
  • 43. 7. Low-code / no-code framework There is a growing market segment that allows businesses to create new applications by uti- lising simple blocks and a GUI that connects them and defines a workflow. We are starting to see many low-code / no-code developers embracing this side of blockchain technology. Also in recent years, the Scratch language has become very popular for educating children, as it allows users to write programs by connecting simple blocks in a graphical interface. Research is needed in order to determine whether such an approach makes sense for blockchain appli- cation development. The following questions need to be answered: • Is there a business need for such an application builder? • Is it feasible within the EOSIO application paradigm? • What will it cost to develop and maintain? Budget estimate for performing the research: see ‘Budgets’. To find out why this is important, click here. 42 EOS Core+ Blue Paper EOS Core+
  • 44. VI. EOSIO for Business and Government I. Overview Open, permissionless, decentralised – these are the first things that might come to mind when thinking of blockchain. For enterprises, the priorities are different. In many cases, a permis- sioned, private chain might better serve their specific needs. Depending on the use case, a consortium or an internal blockchain with a hashing algorithm that sends internal checkpoints to a public network may be more valuable. Such enterprises might also dispense with the ‘tokenomics’ and liquidity aspects of pub- lic networks, which rely on community support to keep the blockchain validated and are not directly influenced by the price of a chain’s native token. The value proposition of blockchain is also variable and depends on the type of industry and use case. Why would an enterprise use the technology? An HFS report (2019) asked more than 300 executives about their organ- isations’ blockchain initiatives, the business impact, and the potential disruptive aspects of the technology: Source: HFS Research in conjunction with Wipro 43 EOS Core+ Blue Paper EOS Core+
  • 45. As we can see, many executives believe blockchain will be more disruptive and transformative to business than even the internet. Leading companies are therefore likely to create new roles and perhaps entirely new departments to migrate themselves into this new digital age. EOSIO has a market share to capture and is uniquely positioned to out-compete the incum- bents of the industry – Hyperledger, Corda, Hedera Quorum. EOSIO presents a significant advantage in its ability to perform as both a public and private solution. We see EOSIO on- boarding both public bodies as well as enterprise customers, who have traditionally shied away from entering the blockchain space. A steady increase of new businesses building on EOSIO will drive value back to public chains such as the EOS Mainnet. • What can we expect from competing and winning market share in enterprise blockchain? • Large scale B2B and government projects • Experienced developers entering the talent pool • New business use cases situated between private and public • An ongoing stream of highly credible positive media PR • Enterprise data integrity and business value secured by EOS Mainnet • The vested interest of big business in the security and governance of EOS Mainnet • Corporate balance sheet investment When EOSIO for Business launched, it created an opportunity for EOSIO to compete in this large and rapidly expanding market. This initiative was halted by Block.one to focus on their in-house products. There were many viable opportunities and partnerships being nurtured and the early indications for the initiative were positive, showing that EOSIO has great potential to penetrate the global business blockchain landscape. 44 EOS Core+ Blue Paper EOS Core+
  • 46. The original EOSIO for Business concept had four well-thought-out pillars: EOSIO Premier Technical Support —presenting companies with easily identifiable support tiers to suit their needs in out- sourcing troubleshooting and technical assistance when launching and maintaining oper- ations for an EOSIO implementation. EOSIO BaaS —an automated blockchain platform fully managed by Block.one, EOSIO BaaS (Blockchain as a Service) allows companies to leverage blockchain technology without having to dedi- cate internal resources to ongoing maintenance. EOSIO Consulting —offers direct access for EOSIO engineers to identify, architect, and implement client blockchain solutions, including the design and implementation of EOSIO smart contracts. EOSIO Training and Certification —comprehensive courses covering the foundations of EOSIO, smart contract program- ming, application development, and best practices for secure integration. Documentation of previous offers is stored in this folder. 45 EOS Core+ Blue Paper EOS Core+
  • 47. Instead of directly replicating these pillars through some centrally-funded entity, we would prefer to foster an ecosystem that would encourage anyone to launch and service a new EOS business customer. A small group of accomplished enterprise EOSIO implementers has already come together out of necessity to form eos.business, focusing on three areas: EOSIO Consulting, Premier Technical support, and Training Certification. The pillar most in need of transformation is EOSIO BaaS (Blockchain as a Service). A single organisation providing BaaS does not align with the principles of our industry. We see a dis- tributed network of companies providing an open suite of tools that allows anyone to configure and run their own BaaS infrastructure. For the business ecosystem to succeed, these four pillars need to be well supported by the ENF (EOS Network Foundation) through the WP+ working groups – Core+, API+, Audit+, and Wallet+. We recommend the ENF focus on building an enterprise-friendly suite of tools, which supports all EOSIO implementers. This model enables our community to deliver products and services that can capture a significant share of the enterprise blockchain market, bring new people to the ecosystem, and drive value back to the community and EOS Mainnet. Image by EOSIO 46 EOS Core+ Blue Paper EOS Core+
  • 48. II. Suite of tools Enterprise Government customers expect their solutions to come with a full set of tools. We see the need for a series of enterprise-focused tools, starting with a Blockchain Configurator, which supports blockchain setup and implementation through to day two operations. The primary tools exist in five main areas: • Setup: to easily install and deploy the EOS blockchain • Block explorer: white-labelled to allow transparent inspection of the blockchain state • Wallet solution: to identify users on the blockchain • Search tool: to search throughout the blockchain for data • Developer environment: to curate well-maintained documentation, libraries, APIs, etc. Enterprise customers will require an additional tool suite consisting of: • Blockchain Configurator • Enterprise Signing Portal • Enterprise focused private chains (white-labelled block explorer) • Enterprise friendly Hyperion / Dfuse solu- tion (History API) • Enterprise Developers toolkit The Enterprise Customers tool suite will have these features: • Platform architecture management • Modularised, preconfigured networks and infrastructure • Easy setup and workflow • Repeatability and scalability • Middleware for app development • Monitoring and alerting services • Dashboard to view and analyse chain code • Auditable transaction records and history • Built-in connections to needed services • Professional consultation services 47 EOS Core+ Blue Paper EOS Core+
  • 49. III. Premier Technical Support The enterprise market demands highly available platforms with Premier Technical Support. Uninterrupted operations, fast response times, and problem resolution are essential to avoid negative business impacts. The customer value proposition is a reduction of risk, optimised Operating Expenses (OPEX), prevention of outages, improved network performance, and Operations and Maintenance (OM) efficiency. This pillar consists of a few components: • Technical Support service: product in- stallation, configuration, or operations • Troubleshooting service: case han- dling provided as per service level agreement (SLA) • Software Update support: bug fix- es packaged and delivered at regular intervals • Preventive Maintenance: ensures the system runs optimally and without interruptions • Emergency Support: 24x7x365, as required • Tiered SLA packages: bronze / silver / gold Image by Rewired.one 48 EOS Core+ Blue Paper EOS Core+
  • 50. How can the ENF help? The ENF aims to lay the foundations for groups like eos.business to come together and launch Premier services for the EOS business ecosystem. Foundational requirements: • Clear and stable Roadmap • An open and well-documented EOS codebase • Quality documentation, training, and education portals • Training and certification programs IV. Blockchain as a Service (BaaS) Enterprise and government are rapidly moving to everything as a service. The popularity of the service-based delivery model means blockchains are a prime candidate for third-party deliv- ery. Take, for example, the AWS Managed Blockchain initiative. The global BaaS market size in 2019 was $1.9B and is expected to grow to $24.9B by 2027. Other research predicts a market size of $94.2B by 2026; in either case, the growth is enormous! EOSIO should have providers offering subscription-based enterprise-grade BaaS solutions where customers receive a myriad of support services and benefits. By building the proper tools (see Blockchain Configurator under Tools), we can enable multiple vendors to become BaaS providers. 1. Consulting Professional services are a vital pillar in this ecosystem, and currently, no centrally coor- dinated blockchain knowledge hub fulfils this condition. Enterprise customers thinking of selecting EOSIO as their blockchain technology will be looking for a consulting network with strategic blockchain knowledge expertise, roadmaps, architecture, design, and implementation capabilities. Recently several EOSIO business implementers came together following Block.one’s decision to drop the EOSIO for Business initiative and commenced work on eos.business to fill the void. 49 EOS Core+ Blue Paper EOS Core+