EOS

Dapps can be extended vertically and horizontally on the EOS platform

home link https://eos.io/

reference material Whitepaper.pdf

Community

Market
4,978.90 KRW
Exchanges that listed the coin
123
Symbol
EOS
Dapp
9
Project introduction

IOS is a 3rd generation password that uses the DPoS method that appeared as an ether killer. It has emerged as an alternative to Etherium's slow processing speed and high commission problem, and aims to create a general purpose block-chain operating system by providing a platform for running DApp, a distributed application. By introducing a new block-chain architecture designed to support both vertical and horizontal expansion of the DapAt, you can eliminate commissions and quickly and easily deploy and maintain your Dap in a block-chain environment.

Executives and partners

Brendan Blumer

CEO

Rob Jesudason

GROUP PRESIDENT

Daniel Larimer

CTO

Andrew Bliss

COO

Steve Ellis

CFO

block.one

Latest News

There is no news posted at the moment
Please leave a message of support for the team

go to leave a message

Medium

Introducing the EOSIO Webin...

The Block.one Developer Relations team is pleased to announce a new learning opportunity for Developers: the EOSIO Webinars Series. These free, live, online events will give seasoned developers as well as newcomers a chance to learn new skills and keep up-to-date with the latest features and capabilities of EOSIO. Members of the Developer Relations team will also be there to field the community’s questions.This initiative is part of our ongoing effort to provide information to new developers looking to learn about creating and enhancing EOSIO-based blockchain applications and advanced tutorials on new functionality to more knowledgeable developers. These live sessions will also be recorded and made available on the EOSIO Developer Portal, so everyone can access an updated and detailed learning resource for themselves or others.The Inaugural Webinar: “Introduction to EOSIO Blockchain Development”The first webinar will be an Introduction to EOSIO Blockchain Development. It will start with an explanation of the general concepts of blockchains, consensus mechanisms, and the unique features of EOSIO blockchains. Participants will also learn about EOSIO smart contracts and tooling, and be taken through a basic example EOSIO smart contract.If you haven’t yet, sign up now for the first webinar, Introduction to EOSIO Blockchain Development, streaming live on July 10th at 8 AM HKT.The full agenda is as follows:What is Blockchain?How Does a Blockchain Work?Consensus ExplainedEOSIO Blockchain SoftwareEOSIO FeaturesEOSIO EcosystemEOSIO Development ToolsEOSIO PlatformNodeos ArchitectureBuilding “hello world!”Accounts and PermissionsActions, Transactions, Communication ModelData PersistenceBuilding a Smart ContractNext StepsStay ConnectedThe EOSIO Webinar Series is just one of the new initiatives that the Developer Relations team has been working on. Future webinars will explore a variety of topics, ranging from specific use cases and industry verticals to technical explorations and deep-dives. We look forward to kicking off the series with you next week, and if you have any suggestions or requests for future events, please send an email to developers@block.one.Find out about Future Webinars & Developer ContentTo stay up to date on future webinars and developer content, sign up for the Block.one Developer Relations mailing list on the EOSIO Developer Portal. We are excited to be regularly improving the usability of the software for EOSIO developers and provide further training and educational resources for the community.Important: All material above and in the webinars and other events is provided subject to this important notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources and forward-looking statements. By accessing any of our material, you accept and agree to the terms of the notice.Originally published at https://eos.io.Introducing the EOSIO Webinar Series was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 07. 08

EOS Virtual Machine: A High...

In Washington, DC at the #B1June event, announcements related to EOSIO™ focused on improved performance and security of the platform. From integration with web standards like WebAuthn, to the announcement of the EOS Virtual Machine (EOS VM), EOSIO 2, the next major version of EOSIO, will further our goal of the mass adoption of blockchain applications. The EOS VM Developer Preview release is still in development and not intended for use in production environments. As we progress toward releasing EOS VM stable, we are excited to be delivering a highly performant WebAssembly interpreter purpose-built for blockchains.Built By Blockchain Engineers for Blockchain ApplicationsWith the ever growing popularity of EOSIO blockchain technology, the performance needed to support the secure deterministic execution of blockchain applications has surpassed the capacity of conventional WebAssembly engines designed to interface with browsers. Over the past year, we tested the performance of existing interpreters like Binaryen and WABT which are well suited for their purpose, but when applied to blockchains have issues with unbounded memory allocation, extended loading time, and stack overflows which lead to decreased overall performance and reliability. Single threaded performance, shared resource tracking, and low-overhead calls to native code are critical to blockchain performance. With these tenets in mind, EOS VM has been engineered from the ground up to meet the specific demands of blockchain applications.EOSIO 1.0 was originally released with the Binaryen interpreter in June 2018, by September we released EOSIO 1.3 with support for WABT seeing 2X performance gains. With the release of EOSIO 2 planned for later this year, we expect EOS VM to increase performance up to 6X more making WebAssembly execution in EOSIO 2 up to 12X faster than when EOSIO was released just one year ago. While we are excited for this improvement in performance, as this is a Developer Preview release, our internal benchmarks are not yet indicative of real world scenarios and further development is ongoing.We built EOS VM to be a high performance interpreter specialized for blockchain applications, but its focus on low latency and other performance efficiencies will make it a competitive alternative for many WebAssembly use cases.High Performance Attributes of the EOS Virtual MachineEOS VM is designed with the following attributes in mind:Extremely Fast ExecutionExtremely Fast Parsing/LoadingEfficient Time Bound ExecutionDeterministic ExecutionC++ / Header Only IntegrationHighly Extensible DesignDeterministic Execution to Avoid Consensus FailuresBlockchain applications require deterministic execution to properly run; given inputs must always produce the same outputs. In using traditional WebAssembly interpreters, non-deterministic actions, those whose values change from state to state, run the risk of delaying consensus affecting all users and applications built on it. With EOS VM, we have engineered an environment that allows for both hardware supported floating point operations and software based floating point operations. The use of the software-based floating point (“softfloat”), allows for true deterministic execution of floating point operations. Since these are built into the system, the overhead for the “softfloat” operations is mitigated as much as possible. For use cases where bit level determinism is not needed, then the library can be configured to use the hardware floating point unit of the host processor.Efficient Time Bounded Execution to Manage ResourcesEffective resource management is key to building performant blockchain applications. Parties of a blockchain network have a finite set of resources that are shared among users of the network. This makes it even more important for blockchain applications to run efficiently within their allotted specifications.EOS VM implements two new tools that allow developers to better manage resource allocation by tracking the WebAssembly runtime execution. The first is a built-in check for the number of WebAssembly instructions that have executed and halt at a preset threshold. This creates a check for processes that start execution but fail to complete gracefully within a set timeframe. The second is an external “watcher” that will halt execution after a preset amount of time, stopping processes that may be hung up and fail to exit gracefully.Securely Built for Real World Blockchain DevelopmentWebAssembly was designed to run untrusted code in a browser environment where the worst that can happen is a hung browser tab. In the case of blockchain, a hung transaction can bring the chain to a halt so the overall consequences are much more severe.Development is an error prone, break-fix process that requires debugging and constant thinking around corners. As a result, there are times when programmers may run into issues with checks and validations. EOS VM’s fundamental data types include built-in protections that trigger and automatically kill execution if many of these corner-cases are hit.To protect memory, we built a guard paging mechanism that utilizes CPU and core OS security to sandbox memory operations. This mechanism allows for more versatile deployment of native code functions without the risk of crashing the machine due to memory overruns related to common programming errors such as unbounded recursion and array access.Built in allocators in EOS VM are modular enough to serve application specific needs without creating memory intensive structures to support them because the allocators don’t “own” the memory they use. Synchronizing the lifetime of such allocators does away with the need to replicate them, allowing for context-independent integration of the WebAssembly modules as needed without any performance loss.C++ / Header Only Integration for Effortless IntegrationEOS-VM can be used in a way that it has no external or pre-compiled dependencies; it is a header only implementation. This means that all macro functions and classes that make up the EOS VM library are visible to the compiler in header files. This allows the compiler to more aggressively optimize EOS VM within the context of the integrating code base, as it has all of the function/method definitions available to it. In this configuration, integration into a project can be as simple as adding the EOS VM directory to the include path of a project.Highly Extensible Component Based DesignCompartmentalizing EOS VM and creating self-contained components allows the system to be highly adaptable to custom backend tools that use newly defined logic alongside previously defined components. In addition, new extensions can be constructed with relative ease by following simple coding procedures, allowing for a robust series of tools capable of profiling, debugging, etc. to arise as necessity dictates.Scaling the Future of Blockchain TechnologyOver the past year growing EOSIO, our focus, along with the community, has been to continue creating more robust toolkits and libraries for EOSIO keeping it one of the most performant and utilized blockchain platforms in the world. Ultimately, the adoption of blockchain technology will be driven by applications which expose the benefits of blockchain to end users and businesses. With the performance advancements of EOS VM, as with all releases of EOSIO, we strive to create tools that will aid developers as they build towards that greater goal. We will continue to work with the community to improve and develop EOSIO to support these endeavors.The EOS VM Developer Preview is not yet released open source. Please refer to the LICENSE for full copyright notice. If interested in contributing to EOS VM please review the Contribution Guide and Code of Conduct noted in the release notes on Github.Stay ConnectedIf you are interested in providing feedback and working more closely with our team to improve EOSIO for developers, you can send our developer relations team an email at developers@block.one.You can also keep up to date with future announcements by subscribing to our mailing list below. We are excited to be regularly improving the usability of the software for EOSIO developers as we continue to lay a foundation for the mass adoption of blockchain technology.Important: All material is provided subject to this important notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources and forward-looking statements. By accessing any of our material, you accept and agree to the terms of the notice.Originally published at https://eos.io.EOS Virtual Machine: A High-Performance Blockchain WebAssembly Interpreter was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 06. 28

EOSIO Labs™ Release: WebAut...

This past weekend in Washington, DC at the B1June event, we announced EOSIO 2 updates on the horizon, which we hope will bring enhanced performance and support for the latest web authentication standards to EOSIO™. EOSIO 2, the next major version of EOSIO, will make using blockchain applications even easier for the masses.Continuing in the spirit of open innovation through EOSIO Labs™, we have released a WebAuthn Example App to demonstrate how we intend to implement WebAuthn support for EOSIO.This EOSIO Labs release follows suit of our recent releases focused on key and password management streamlining the EOSIO authenticator ecosystem. From the Assert Manifest Security Model to the Universal Authenticator Library, and our most recent release of iOS and Chrome Extension Authenticator Reference Applications, we are dedicated to exploring the future of seamless security on EOSIO.Securing EOSIO blockchain applications with WebAuthn SupportWebAuthn is a new World Wide Web Consortium (W3C) standard accepted and pioneered globally by many major technology companies like Yubico, Google, and Microsoft, that enables secure authentication supported by all leading browsers and platforms.To our knowledge, EOSIO is the first blockchain protocol to adopt the WebAuthn standard. As a new security standard approved by the W3C, we are excited to be pioneering its adoption within the blockchain community.Bringing this standard to EOSIO opens up the possibility of more secure and seamless transaction signing for blockchain applications built on EOSIO. Rather than worrying about private keys, users will be able to sign transactions using their choice of standard hardware authenticators (rather than Chrome extensions or applications) such as the newly announced EOSIO YubiKey and built-in platform authenticators like fingerprint sensors and other biometrics.More information about WebAuthn can be found at https://webauthn.guide.WebAuthn Example Web App for EOSIO YubiKey SupportThis example app is meant purely for demonstration purposes and should not be deployed in its current form into any production environments. It is meant to illustrate how an application running on a private EOSIO based blockchain could generate WebAuthn-compatible keys for users and request signatures from users with those keys to sign transactions.This is facilitated by eosjs, a WebAuthn Signature Provider for eosjs, and the built-in browser Web Authentication API. The browser prompts the user to authenticate with their security key or built-in platform authenticator.While users will have their choice of authenticator or biometric key that supports WebAuthn, we are excited to have announced that Block.one will be working with Yubico to provide EOSIO branded YubiKeys for EOSIO users and developers to use with blockchain applications. More information about the sale of EOSIO YubiKeys is available on the Build on EOSIO section of the EOSIO Website.Existing Limitations to WebAuthn on EOSIOAs this is an example web app being released under EOSIO Labs, there are still a number of limitations we hope to work through before bringing this standard to full support in production environments. You can read more detail about these limitations in the WebAuthn Example Web App GitHub repository.Most importantly, there is currently no way to display Ricardian contracts to users when using WebAuthn. For this reason, WebAuthn, when used in conjunction with EOSIO, should be used with caution and only on private chains and applications already trusted by the end user.We will continue working to test and enhance WebAuthn support for EOSIO before its official release outside of EOSIO Labs. We believe that the answers to many of these limitations lie with the active and engaged EOSIO community. We hope that this open source release will inspire EOSIO developers to explore how this web security standard will impact the future of authentication on EOSIO based blockchains and applications.If you have questions, suggestions, ideas, etc., get involved. We invite you to log issues or submit Pull Requests against this repo.Stay ConnectedIf you are interested in providing feedback and working more closely with our team to improve EOSIO for developers, you can send our developer relations team an email at developers@block.one.You can also keep up to date with future announcements by subscribing to our mailing list on the new EOSIO website. We are excited to be regularly improving the usability of the software for EOSIO developers as we continue to lay a foundation for the mass adoption of blockchain technology.All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and non infringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate. Any person using or offering this software in connection with providing software, goods or services to third parties shall advise such third parties of these license terms, disclaimers and exclusions of liability. Block.one, EOSIO, EOSIO Labs, EOS, the heptahedron and associated logos are trademarks of Block.one. Other trademarks referenced herein are the property of their respective owners. Please note that the statements herein are an expression of Block.one’s vision, not a guarantee of anything, and all aspects of it are subject to change in all respects at Block.one’s sole discretion. We call these “forward looking statements”, which includes statements in this document, other than statements of historical facts, such as statements regarding EOSIO’s development, expected performance, and future features, or our business strategy, plans, prospects, developments and objectives. These statements are only predictions and reflect Block.one’s current beliefs and expectations with respect to future events; they are based on assumptions and are subject to risk, uncertainties and change at any time. We operate in a rapidly changing environment. New risks emerge from time to time. Given these risks and uncertainties, you are cautioned not to rely on these forward-looking statements. Actual results, performance or events may differ materially from what is predicted in the forward-looking statements. Some of the factors that could cause actual results, performance or events to differ materially from the forward-looking statements include, without limitation: market volatility; continued availability of capital, financing and personnel; product acceptance; the commercial success of any new products or technologies; competition; government regulation and laws; and general economic, market or business conditions. All statements are valid only as of the date of first posting and Block.one is under no obligation to, and expressly disclaims any obligation to, update or alter any statements, whether as a result of new information, subsequent events or otherwise. Nothing herein constitutes technological, financial, investment, legal or other advice, either in general or with regard to any particular situation or implementation. Please consult with experts in appropriate areas before implementing or utilizing anything contained in this document.EOSIO Labs™ Release: WebAuthn Example Web App for EOSIO YubiKey Support was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 06. 07

EOSIO Labs™ Release: iOS an...

Last month, we introduced EOSIO Labs™, an initiative centered on open innovation. Through EOSIO Labs we can contribute to the conversation around the future of blockchain technology with thought leadership, tools, and software. From the Assert Manifest Security Model to the Universal Authenticator Library, and our most recent release, the EOSIO Explorer, this initiative is well underway.To date, much of our Labs research has focused on key and password management and the EOSIO™ authenticator ecosystem, and for good reason. Blockchain authenticators as key managers serve, for users, as the gateway to interacting with blockchain-based applications. They are a critical component of the user’s security and overall experience, and, for that reason are critical to the mass adoption of blockchain technology.Today, there are several excellent authenticators in the EOSIO ecosystem. The community is innovating at an incredibly swift pace and blockchain-enabled experiences are becoming more and more accessible because of it. Nonetheless, more work is needed if we are to continue fueling widespread adoption and use of this technology.EOSIO Reference Authenticator AppsToday’s EOSIO Labs release ties several of our recently-announced tools, software, and thought leadership pieces together into one, cohesive experience that aims to address some of the security and usability concerns users currently face. We are excited to release the EOSIO Reference Authenticator Apps.To be clear, the implementations we are showcasing today are being released as experimental reference Open Source Software and not as proprietary products for uploading on app stores (and we discourage anyone from doing so). By releasing them in this way, we hope to encourage ongoing improvements to the security, interoperability and usability of authenticators by contributing working code and examples.EOSIO Reference iOS Authenticator AppThe EOSIO Reference iOS Authenticator App is an implementation on iOS that allows users to sign in and approve transactions from 1) web applications running in Mobile Safari and 2) other native iOS apps on the same device. Key management and signing take place in Apple’s Secure Enclave and/or Keychain and are protected with the device’s biometric authentication.To achieve this, the app leverages the recently-announced EOSIO SDK for Swift library and the EOSIO SDK for Swift: Vault Signature Provider.Example: Authenticating and Signing a Transaction from a Third-Party Mobile Web AppEOSIO Reference Chrome Extension Authenticator AppThe EOSIO Reference Chrome Extension Authenticator is an implementation that allows users to sign in and approve transactions from web applications running in Google Chrome on desktop. Key management and signing take place in the Chrome extension secured by a passphrase.Example: Authenticating and Signing a Transaction from a Web App in Google Chrome on DesktopIntegrating ApplicationsWeb applications integrate with the EOSIO Reference Authenticator Apps using the Universal Authenticator Library and the EOSIO Reference Authenticator plugin for UAL. This release also includes an example web application called Tropical Stay which demonstrates how this works. Alternatively, apps can directly use EOSJS along with the appropriate signature provider.Native mobile applications are able to integrate with the iOS app using EOSIO SDK for Swift and the Reference iOS Authenticator Signature Provider for the SDK.Key Features and InnovationsSeamless, Multi-Chain SupportDuring our research, we noticed that many popular authenticator applications support only one EOSIO based blockchain — for example, the EOS Public Network. Those that support other chains often require users to configure the authenticator with RPC endpoints or networks so that their authenticator can communicate with the chain(s) their app interacts with.This presents quite the challenge for ordinary users with complexity that will only increase as more EOSIO-based blockchains are launched. Indeed, it’s not hard to imagine a future in which applications operate their own app-specific chains.We set out to address this friction by making the EOSIO Reference Authenticator Apps entirely chain agnostic. In fact, the Authenticator Apps do not communicate with EOSIO nodes directly, at all.This is achieved by ensuring that all of the information required to display and sign a transaction is passed in by the application proposing the transaction. [See: EOSIO Authentication Transport Protocol Specification.] After the transaction is signed in the Authenticator App, the signatures are returned to the proposing app. It’s the job of the proposing app to broadcast the transaction.There are no RPC endpoints to configure. Any EOSIO chain is supported. And it’s all secured by the Assert Manifest Security Model.Works Without Requiring Users to Change Browsing HabitsAnother observation we made was that many popular authenticators — especially those on mobile — require users to fundamentally change their browsing habits if they want to use blockchain-enabled web applications. In these authenticators, users are expected to browse these blockchain-enabled web applications from within the confines of a specialized, in-app blockchain web browser instead of just working with the users’ everyday web browser of choice. Furthermore, most authenticator apps on mobile platforms do not support inter-application transaction signing (i.e., signing transactions proposed by other native mobile apps.)The EOSIO Reference iOS Authenticator App allows users to sign in and approve transactions from web applications running in Mobile Safari as well as other native iOS apps on the same device. This is accomplished using the EOSIO Authentication Transport Protocol and the Deep Linking URL Query String transport.Enhanced App IdentificationThe EOSIO Reference Authenticator Apps demonstrate another key feature — that of domain-verified, chain-attested app identification. During selective disclosure (i.e., sign in) and transaction signing requests, apps are clearly identified to the user by an app name, icon and domain. These, along with other metadata, are retrieved from an application manifest served from the app’s domain and are asserted as part of the transaction. For more information on how this works, and its related benefits, see our previous EOSIO Labs Release: The Assert Manifest Security Model.Richly-Rendered Ricardian ContractsEOSIO provides for rich Ricardian contracts that plainly explain to users the action or actions they are agreeing to. Many wallets, however, do not take advantage of the ability to display these agreements to their users. And some resort to displaying the contents of the transaction to their users in formats which are intended to be parsed by computers, not humans (e.g., JSON, YAML).Both the Chrome Extension and iOS Reference Authenticator Apps leverage the Ricardian Template Toolkit to provide users with a consistent, transparent, and user-friendly presentation of transaction data during the signing process. For more information, see our recent EOSIO Software Release: Ricardian Contract Specifications and the Ricardian Template Toolkit.The Future of AuthenticationWhile these reference implementations provide interesting, and hopefully compelling, solutions to some of the limitations and issues users face with blockchain wallets today, they are by no means the ultimate solution. We are submitting them to the community as part of the continuing conversation around what the user experience could be. There are still questions to answer, problems to solve, and possibilities to explore. For example:How do we provide a safe and intuitive whitelisting/autosign experience for users on mobile? The EOSIO Reference Authenticator Apps currently only support manual signing.If keys are generated in a secure element, such as Apple’s Secure Enclave, how do they get added to a user’s blockchain accounts in a seamless, secure and user-friendly way? And how does this work smoothly in a world with many EOSIO chains?If keys are stored irretrievably within a secure element, what happens when a user loses their device? How does backup and recovery work without a third-party custodian? And how can multi-device syncing be facilitated?How do we abstract all of the complexity of blockchain away from everyday users who simply want to interact with their websites and apps without having to think about whether or not they’re backed by a blockchain. More generally, how do we bring the security and transparency benefits of blockchain to the masses without sacrificing convenience and usability?Could a blockchain authenticator like this one replace passwords on the web entirely? Could tools like this become general-purpose authenticators that happen to also bring the power of blockchain to everyone using them?Those last questions are especially interesting and are the topic of our recent article, “A Passwordless Future: Building Towards More Secure and Usable Authentication Systems.”We believe that the answers to many of these questions lie with the active and engaged EOSIO community. We hope that this open source release, and the many ideas that it brings together will inspire wallet developers to explore new ways of thinking about key management and signing for blockchain, and authentication more generally.Next StepsIf you would like to try the EOSIO Reference Authenticator Apps out for yourself, here are a few resources to get you started:EOSIO Reference iOS Authenticator AppGithub READMEGetting started with an example appEOSIO Reference Chrome Extension Authenticator AppGithub READMETropical Example Web AppIf you have questions, suggestions, ideas, etc., get involved. We invite you to log issues or submit Pull Requests against these repos. Or fork them and innovate on your own.Stay ConnectedIf you are interested in providing feedback and working more closely with our team to improve the EOSIO for developers, you can send our developer relations team an email at developers@block.one.You can also keep up to date with future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be regularly improving the usability of the software for EOSIO developers as we continue to lay a foundation for the mass adoption of blockchain technology.All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate. Any person using or offering this software in connection with providing software, goods or services to third parties shall advise such third parties of these license terms, disclaimers and exclusions of liability. Block.one, EOSIO, EOSIO Labs, EOS, the heptahedron and associated logos are trademarks of Block.one. All other trademarks referenced herein are the property of their respective owners.EOSIO Labs™ Release: iOS and Chrome Extension Authenticator Reference Applications was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 05. 29

EOSIO Labs™ Release: The EO...

Block.one is pleased to announce the release of EOSIO Explorer, a new web-based graphical user interface to improve the developer experience of interacting and monitoring EOSIO-based applications and networks in development.Previously, developers would have to use a command-line based toolchain that, while functional, is less user-friendly and more difficult for developers who prefer a visual interface. Using the EOSIO Explorer and their browser, developers can now easily explore blocks in their development nodes, create and manage their development accounts and keys, quickly generate new transactions or resend transactions sent previously, upload smart contracts via a graphical drag-and-drop interface and use other helpful features.The EOSIO Explorer builds on previous releases from Block.one, aimed at making development on the EOSIO codebase more user-friendly and accessible to all types of developers. Most importantly, this tool helps developers reduce EOSIO app development time through a number of ways and makes EOSIO smart contract development more accessible to a diverse cohort of developers.The tool has been built with developers and development teams in mind, supporting both smart contract developers and front-end EOSIO app developers. Teams are able to work together using the EOSIO Explorer via the local single-node testnet that the tool provides.EOSIO Explorer FunctionalityThe EOSIO Explorer features are split into two groups:InspectInspecting features allow developers to view connected blockchain information, individual block, transaction and action details, and accounts details with associated smart contracts. This is most useful for verifying data transmitted between an application and the blockchain and verifying functionality of a smart contract.InteractInteracting features allow developers to edit, import and create development accounts — with relevant public and private key pairings, upload and deploy smart contracts and generated ABIs, and push actions coded in smart contracts. This is most useful for user testing and verifying accounts interacting with your application.Stay Connected with EOSIO LabsThrough EOSIO Labs, Block.one will continue releasing our thoughts and research on projects like this for the EOSIO developer community. Creating developer tools like the EOSIO Explorer marks another step towards improving the developer experience on EOSIO. We welcome continued community support in shaping how to grow this tool to be most valuable in the development process.If you are interested in providing feedback and working more closely with our team to improve the EOSIO Labs repositories for developers, you can post issues and pull requests on GitHub or send our developer relations team an email at developers@block.one.You can also stay informed of future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be regularly improving the usability of the software for EOSIO developers as we continue to lay a foundation for the mass adoption of blockchain technology.Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate. Any person using or offering this software in connection with providing software, goods or services to third parties shall advise such third parties of these license terms, disclaimers and exclusions of liability. Block.one, EOSIO, EOSIO Labs, EOS, the heptahedron and associated logos are trademarks of Block.one. All other trademarks referenced herein are the property of their respective owners.EOSIO Labs™ Release: The EOSIO™ Explorer was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 05. 21

EOSIO™ Software Release: Na...

New Open Source Tools to Create First-Class Mobile Experiences on EOSIO™In a very short period of time, we’ve witnessed an explosion of innovative EOSIO web applications due in large part to libraries like EOSJS. EOSJS, with over 5,000 weekly downloads, provides JavaScript developers with the tools they need for interacting with EOSIO blockchains, and for realizing the promise of blockchain technology for users around the world.As we all know, however, users are spending more of their time on mobile devices in native applications. This is largely because native apps are often able to provide richer, more engaging experiences than their browser-based counterparts. Today, native mobile applications are a crucial component of consumer-facing product strategies.It is for this reason that we are excited to announce the alpha release of two new open source EOSIO tools to enhance native mobile application development on EOSIO, an EOSIO SDK for Swift and EOSIO SDK for Java.Developer Convenience, Flexible ArchitectureThese Software Development Kits (SDKs) provide native APIs for interacting with EOSIO blockchains; creating, signing and broadcasting transactions; handling keys and obtaining signatures; data serialization/deserialization, and more.And by targeting both the Java and Swift programming languages, we’re bringing these capabilities to the most popular mobile platforms — Android and iOS — contributing to what we hope will be a proliferation of compelling, native EOSIO-powered experiences for mobile users everywhere.These SDKs employ a concept borrowed from EOSJS that provide a great deal of flexibility for a variety of use cases and environments — that of independent, interchangeable providers that plug into one core library.The Core LibrariesThe core EOSIO SDK for Swift and EOSIO SDK for Java libraries are responsible for facilitating the transaction lifecycle. They provide developers with easy and idiomatic ways of creating and working with transactions, collecting the necessary signatures, and preparing and broadcasting those transactions to EOSIO nodes. Much of the heavy lifting, however, takes place in the providers that are plugged into it.The Signature ProviderThe Signature Provider is arguably the most flexible of all of the provider abstractions. It is responsible for a) finding out what keys are available for signing and b) requesting and obtaining the signatures required for the transaction.How it goes about executing that, though, is entirely up to the particular signature provider the developer has chosen to “plug in” for that transaction. By simply switching out the signature provider, signature requests can be routed in any number of ways.A signature provider is able to carry out a number of useful functions. For example, anyone who needed a signature from keys in the platform’s key store or secure hardware signing element can simply configure the transaction with a signature provider that does it. The same goes for needing signatures from a wallet app running on a user’s device, which a signature provider can also perform.This is great news for both app developers and users. For developers, this feature means that depending on their selection of signature providers, they no longer have to be on the hook for handling and securing a user’s private keys. For users, it means that the apps they love can easily work with the wallet or authenticator of their choice, creating a win-win situation.Along with the core libraries, we are releasing the following signatures providers, in alpha.EOSIO SDK for Swift: Vault Signature Provider: Signature provider implementation for signing transactions using keys stored in Apple’s Keychain or the device’s Secure Enclave.EOSIO SDK for Swift: Softkey Signature Provider: Example signature provider for signing transactions using keys in memory.EOSIO SDK for Java: Softkey Signature Provider: Example signature provider for signing transactions using keys in memory.As always, we encourage others in the community to create and open source other signature providers.For more information about the signature provider concept, check out our previous article: EOSJS Major Update V20.0.0 Beta: Entrusting key management to signature providers for a more secure future of javascript development for EOSIOThe RPC, ABI, and Serialization ProvidersTransactions are also configured with RPC, ABI, and Serialization providers.RPC Providers are responsible for all RPC calls to nodeos, as well as general network handling (reachability, retry and failover logic, etc.)Serialization providers handle ABI-driven transaction and action serialization and deserialization between JSON and binary data representationsABI providers are responsible for fetching and caching ABIs for use during serialization and deserializationWhile the need to swap these providers is less frequent, the abstraction is still quite valuable, especially when it comes to one of these SDKs’ other value propositions — support for platforms other than mobile.Mobile and BeyondIt is important to note that both Java and Swift are general purpose programming languages, and that they are not restricted to running on mobile platforms. In fact, Java, with its “write once, run anywhere” philosophy, precedes Android and is virtually ubiquitous.With that in mind, we have purposefully set out to make the core SDK libraries as generic and platform agnostic as possible, relegating any platform-specific code to the individual provider libraries.While we have only tested the alpha versions of EOSIO SDK for Java on the Android platform and EOSIO SDK for Swift on iOS, when instantiated with the right platform-compatible providers, the core library should run with little additional effort. We welcome the community to contribute by testing the core libraries on other platforms and creating issues and pull requests that improve compatibility with those platforms.Get Started and Get InvolvedWe have several resources for those interested in using these libraries and/or contributing.Example AppsTo help developers get started using these new SDKs, we have created both iOS and Android example applications. These examples are simple demonstrations of how to integrate with EOSIO-based blockchains using the EOSIO SDKs. The applications do two things: they fetch your account token balance and push a transfer action.DocumentationEOSIO SDK for Swift: Documentation: https://eosio.github.io/eosio-swiftEOSIO SDK for Swift: Github Repo: https://github.com/EOSIO/eosio-swiftEOSIO SDK for Java: Github Repo: https://github.com/EOSIO/eosio-javaStay ConnectedIf you are interested in providing feedback and working more closely with our team to improve the EOSIO for developers, you can send our developer relations team an email at developers@block.one.You can also keep up to date with future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be regularly improving the usability of the software for EOSIO developers as we continue to lay a foundation for the mass adoption of blockchain technology.. . .All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate. Any person using or offering this software in connection with providing software, goods or services to third parties shall advise such third parties of these license terms, disclaimers and exclusions of liability. Block.one, EOSIO, EOSIO Labs, EOS, the heptahedron and associated logos are trademarks of Block.one. All other trademarks referenced herein are the property of their respective owners.EOSIO™ Software Release: Native SDKs for Swift and Java was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 05. 17

EOSIO Labs™ Release: The As...

Last month, we announced EOSIO Labs™, an initiative through which we have begun innovating in the open with regards to the future of blockchain technologies built on EOSIO. Our first release under this initiative explored the future of private key management and its implications on security and key management — the Universal Authenticator Library (UAL).This post continues the EOSIO Labs series, expanding on the ideas of EOSIO Manifests, Assert Contracts, and the Security Model behind them to increase user confidence when signing transactions on blockchain applications.A Layered Security ModelPublic, permissionless blockchains by definition enable any application to access any contract on the blockchain on behalf of a valid user of the blockchain. This open architecture enables numerous providers to build applications that meet users’ needs. However, inherent in this openness is a set of issues:Applications can misrepresent who they are to the user during signing (e.g., falsely claim to be the official app for example.com)Applications can misrepresent what the user is signing (e.g., request signatures for actions the user did not authorize)Here we present a layered security model that abstracts the who and what concerns as an application concern that is separate from the way actual transaction signatures are achieved in trusted authenticators (transaction signer).First we introduce the concept of Application Manifests that help validate the source of the application, answering the “who do you legitimately represent?” question. Second, we introduce the Assert Contract installed on the destination chain that provides assurance thatthe transactions being posted by the application are legitimate by validating transaction contents against the on-chain contents of the Application Manifest. For simplification, we present Application Manifests and the Assert Contract as having the two clearly defined purposes outlined above. In reality, they share responsibility with a series of related tools like Ricardian renderers, authorization transport protocols, and others, to help deliver a secure and trusted experience to blockchain users.The Security ModelThe Application Manifest and the Assert Contract work together with conforming authenticators that have the ability to display the Ricardian contracts to solve the who and what problems outlined above. It is important to note that under this model authenticators do not communicate directly with the blockchain on behalf of the application. Authenticators securely sign transactions on behalf of the user and return the transaction to the application, which then broadcasts it to the respective chain. For reference, Figure 1 is a summary of the flow we detail below.Fig 1: Assert, Manifest Spec, and Ricardians supported Security Model SchematicApplication ManifestThe Application Manifest publicly declares metadata about the decentralized application and the list of actions the application is permitted to broadcast to a particular smart contract. This declaration is made both on-chain, and at a well-known location on the application’s web domain. Taken together, these two declarations working in concert with the Assert Contract will enable the trusted authenticator to provide assurances that:The application requesting a transaction signature is an authorized application for that domain. When an application requests a transaction signature, the authenticator can enforce the same-origin policy and verify that the application provided manifest and the copy of manifest that lives at the web domain of the application are hash verifiable. This allows users to trust that they are dealing with a legitimate application for that domain as only legitimate users in control of their domain can host the manifest at that location. In addition, this also allows for application resources like icons to be hash verified as necessary.The action being requested by the application is legitimate by comparing it against the list of permitted actions in the manifest, preventing an application from maliciously requesting a transfer of tokens if that action is not listed in the whitelist for a blockchain game or ride sharing application, for example.Under this model, we also provide tools and renderers to enable trusted authenticators, which can display rich Ricardian contract content to the end users and enable them to verify the exact contents of the transaction they are authorizing. The Manifest Specification provides additional details of the above flow. The Ricardian Spec and Ricardian Template Toolkit provide tools for authenticators to render Ricardian contracts. In addition to reviewing the repositories on GitHub, you can read more about Ricardians in our recent release post on Medium.Assert ContractThe Assert Contract installed on the destination chain works in concert with the Application Manifest to ensure transactions being posted by the application are legitimate by validating transaction contents against the on-chain contents of the Application Manifest. Trusted authenticators under this model will add an assert::require action to all transactions forcing validation of key details of the Application Manifest on chain. This action is intended to ensure that if any of the details provided by the application don’t match the on-chain details, then the entire transaction fails, protecting the end user.In particular, the Assert Contract:Allows blockchain networks to register the official chain name and chain icon.Allows decentralized application developers to register one or more manifests describing their application and to remove previously registered manifests.Allows users (via a trusted authenticator) to include an assert::require action in a transaction that will ensure that the entire transaction is rejected if the required pre-conditions are not valid.Trusted authenticators can now run transaction pre-flight security assertions with the Assert Contract comparing the contents of a transaction request with the list of permitted actions the applications have declared. These assertions include comparing the hash of the Application Manifest, the hash of the app-provided chain info, the hashes of ABIs provided by the app (including the Ricardians presented to the user) against the hash of the matching ABIs on chain to validate that the contract presented to the user for the given action was not tampered with.Keen observers of this model will note how the security model is geared to maintaining the logical separation of a trusted authenticator from decentralized applications. Authenticators that conform to this model simply add a well-known assert action to all transactions for a given chain to secure end users.We invite the community to explore if, in the future, application contract developers can also choose to examine incoming transactions to verify that it contains the same well-known assert action before processing the transaction further. This check could provide another on-chain transaction verification mechanism. The Assert Contract provides additional technical details.The BenefitsThis layered application architecture enables trusted authenticators to be excellent custodians of users’ private keys and remain clearly delineated from application-specific actions while still enforcing a security model that provides additional assurances to the end user. This way, blockchain users do not have to review all the source code associated with every decentralized application before using them since the components of the security model in themselves provide significant assurances for the end-user to confidently interact with the blockchain.Some of the benefits of this approach are:Transactions that do not conform to the Application Manifest are rejected outright by the trusted authenticator and never get broadcast to the blockchainTransactions that make it to the chain from trusted authenticators are still verified against the Application Manifest contents on chainApplication search engines can listen to manifest registrations and build a comprehensive listing of known decentralized applications for end users to choose fromThe model also provides a way for application developers to defend themselves against incorrect accusations made by end-users when malicious third parties commit fraud by impersonating their applicationHowever, this model in itself does not solve all the issues associated with imposters. If the user does not pay attention to the displayed Ricardians in a secure authenticator prior to signing the transactions proposed by applications from bloçkçhainapplication.com instead of those from blockchainapplication.com — this model fails to protect users from such imposters. We invite ideas from the community on how the framework can be extended to handle such attack vectors. We consider the model laid out here as a starting point for initiating the discussion with the community and we look forward to hearing from you.Stay ConnectedIf you are interested in providing feedback and working more closely with our team to improve the EOSIO Labs repositories for developers, you can post issues and pull requests on GitHub or send our developer relations team an email at developers@block.one.You can also stay informed of future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be continually improving the usability of the software for EOSIO developers as we continue laying a foundation for the mass adoption of blockchain technology.The Future is Open for EOSIO LabsThrough EOSIO Labs, Block.one will continue releasing our thoughts and research on projects like this for EOSIO. This is just the first of many areas of research we hope to tackle as part of the community. We welcome and encourage your feedback on areas of interest to explore and look forward to continually growing one of the most vibrant and innovative technology communities in the world.Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate. Any person using or offering this software in connection with providing software, goods or services to third parties shall advise such third parties of these license terms, disclaimers and exclusions of liability. Block.one, EOSIO, EOSIO Labs, EOS, the heptahedron and associated logos are trademarks of Block.one. All other trademarks referenced herein are the property of their respective owners.EOSIO Labs™ Release: The Assert Manifest Security Model was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 05. 10

EOSIO™ Version 1.8.0-rc1:

EOSIO™ Version 1.8.0-rc1: EOSIO Consensus Protocol Upgrade Release Candidate for Enhanced Security and Usability FeaturesAs a contributor to the development and enhancement of the EOSIO software, we are pleased to announce a release candidate is available for EOSIO. You can find more details about EOSIO v1.8.0-rc1 in the GitHub repository. Documentation on the EOSIO Developer Portal will be updated by the stable release and recommendations for anyone operating a node for an EOSIO blockchain network are available in GitHub.This release candidate marks a major update for the EOSIO software platform: a consensus protocol upgrade, which implements a change to the protocol rules and requires alignment by block producing nodes for the upgrade to be successfully deployed. Please note, this is a Release Candidate for feedback, the official release will be marked stable in the coming weeks once we have finished vetting and testing the update with the community. The latest STABLE release is v1.7.3.When this release is promoted to stable, foundational mechanisms will be introduced to facilitate the activation of the consensus protocol upgrade. More specific details on these mechanisms are available in issues #6429, #6431, and #6437 in the GitHub repository for the EOSIO software. These mechanisms will allow a two-thirds majority of active block producers of EOSIO blockchains to activate individual features of the consensus protocol upgrade to modify the protocol rules. All nodes will need to be locally configured to accept these upgrades, which can be as simple as installing a new version of the nodeos software. Each feature is for the most part designed to be à la carte, i.e. each feature can be activated independently of one another, however, some features may have dependencies on other features as noted in each issue.Continue reading below for an overview of the initial protocol upgrade features in this release and their implications to developers and users of EOSIO platforms:Protocol upgrade features in EOSIO v1.8.0-rc1 Release Candidate:(#6431) Enable protocol feature pre-activationCodename: PREACTIVATE_FEATUREThis feature is actually part of the foundational mechanisms to facilitate activation of consensus protocol upgrades and will, therefore, need to be the first feature that is activated. Some features will be configured to require pre-activation on the blockchain. This enables replacing the subjective block producer policy of when to activate a particular feature with an objective on-chain policy carried out via smart contracts. Typically this objective on-chain policy will be in the form of requiring more than two-thirds of active block producers to approve an on-chain multisig transaction proposal which would execute a special system contract action to pre-activate the particular feature. The PREACTIVATE_FEATURE feature must be activated before the new version of the system contract with that special action can be deployed since the action implementation will require a privileged intrinsic function only made available after PREACTIVATE_FEATURE is activated.(#6333) Disallow linking to non-existing permissionCodename: ONLY_LINK_TO_EXISTING_PERMISSIONThis disallows linking an action (via the eosio::linkauth native action) to a non-existing permission. Missing this check should not create any security issues; it is only to avoid an inconvenience for the user.(#6672) Fix excessive restrictions of eosio::linkauthCodename: FIX_LINKAUTH_RESTRICTIONThis relaxes the unintentionally restrictive limitations on which actions can be linked to a minimum required permission. Subjective mitigation cannot fix this bug. However, the bug is not a security issue. It simply means that until this feature is activated, contract developers should not name their actions updateauth, deleteauth, linkauth, unlinkauth, or canceldelay so that their users do not run into any trouble with setting custom minimum permissions for the contract’s actions.(#6458) Disallow proposing an empty producer scheduleCodename: DISALLOW_EMPTY_PRODUCER_SCHEDULEThis disallows a contract from proposing an empty producer schedule. No subjective mitigation is needed for this bug because: proposing an empty producer schedule does no harm; and, only privileged contracts, such as the system contract, are allowed to propose producer schedules changes anyway.(#6705) Restrict authorization checking when sending actions to selfCodename: RESTRICT_ACTION_TO_SELFThis would remove the authorization checking bypass that applied when a contract sent an inline action to itself or when it sent a deferred transaction consisting of only actions to itself. Subjective mitigation to restrict the authorization bypass was already released. This feature goes further in the restriction and makes it objective so that the authorization checking behavior for all actions becomes consistent regardless of whether the actions are the original actions in an input transaction, actions included in a contract-generated transaction, or inline actions sent by a contract. Block producers should be aware that activating this feature could break existing contracts that rely on the remaining activate authorization bypass that this feature would remove.(#6103) Fix problems associated with replacing deferred transactionCodename: REPLACE_DEFERREDAn issue exists with the current mechanism to replace an existing deferred transaction using the send_deferred intrinsic function. First, the RAM used to store the original deferred transaction is not returned back to the original payer. Second, the transaction ID of the original deferred transaction persists, which means the new deferred transaction could retire in a block with the incorrect transaction ID. Fixing these issues requires a consensus protocol upgrade, which is what this feature does. This feature will also correct the RAM usage of any accounts that have already been affected by this bug. Currently, EOSIO software has a subjective mitigation to disallow replacing existing deferred transactions using the send_deferred intrinsic function. That subjective mitigation will be removed when this feature is activated.(#6115) Avoid transaction ID collision of deferred transactionsCodename: NO_DUPLICATE_DEFERRED_IDThe prior issue with replacing deferred transactions could lead to a deferred transaction retiring with a transaction ID that is a repeat of a prior retired transaction. But this is not the only way a deferred transaction could end up with the same ID as another transaction in the blockchain with the current protocol rules of EOSIO. Various stakeholders, particularly block explorers, would benefit from a guarantee of it being virtually impossible for any two distinct transactions within a blockchain to have the same transaction ID. This feature, which depends on REPLACE_DEFERRED feature, makes the changes necessary to enable that guarantee. Block producers should be aware that activating this feature will slightly change the structure of the deferred transactions provided to the onerror handlers of contracts; for details of this change and the impact it may possibly have on existing contracts, see this comment.(#6105) Modify restrictions on RAM billingCodename: RAM_RESTRICTIONSA prior released subjective mitigation disallowed unprivileged contracts executing under the context of an action notification from billing any RAM to accounts other than self. Rather than simply making this restriction objective, this feature takes a more flexible approach which still achieves the same goal of disallowing an unprivileged contract executing under a notification context from increasing the RAM usage of any other account by the end of the action. However, it also allows unprivileged contracts executing an action (whether under a notification context or not) to carry out database operations which bill RAM to another account, despite no authorization on the action from that account, as long as by the end of the action the RAM usage of the account has not increased.(#6332) Only bill CPU and network bandwidth to the first authorizer of a transactionCodename: ONLY_BILL_FIRST_AUTHORIZERThis feature changes the CPU and Network usage billing behavior of EOSIO blockchains to only charge the first authorizer of the transaction. This one change enables entrepreneuring application developers to build alternative models for paying the CPU and Network resource costs that a transaction imposes on the blockchain network. For example, an application can be designed to pay the CPU and Network costs of their users but only for transactions by the user that solely interact with the application’s services.(#6988) Forward setcode action to WebAssembly code deployed on eosio accountCodename: FORWARD_SETCODEThis feature changes how the eosio::setcode action is dispatched so that, when activated, the WebAssembly system contract code has a chance to execute when a contract is set on some account. By allowing the WebAssembly code to run, it opens up different possibilities of enforcing on-chain policies regarding the deployment of contracts.(#7028) Allow contracts to determine which account is the sender of an inline actionCodename: GET_SENDERThis feature adds a new intrinsic function called get_sender which allows contracts to determine which account is the sender of an inline action. This can enable a more flexible method for a contract to notify another contract of an event by sending an inline action rather than using require_receipient while still remaining resistant to spoofing attempts thanks to the new intrinsic function.Be sure to review the EOSIO v1.8.0-rc1 repository in detail for a full explanation of all the features in this release.Recommended upgrade process for all EOSIO based blockchain networks:In GitHub, we have detailed recommendations for anyone operating a node for an EOSIO blockchain network to adequately test and update their systems for each feature to be implemented. All node operators (including non block-producing nodes) should review the suggested instructions as soon as possible because updating to EOSIO v1.8.0 will require a replay from genesis which can take some time. These steps should be followed on an additional node that you can afford to take offline for an extended period of time.Before deploying the upgrade to any non-test networks, protocol upgrades should be deployed and verified on test networks. Existing EOSIO test networks can use EOSIO v1.8.0-rc1 released today to carry out and test the upgrade process.This test upgrade process can give Block Producers of their respective EOSIO blockchain networks practice with carrying out the steps necessary to successfully coordinate the activation of the first feature, which will fork out any nodes that have not yet updated to the new version of nodeos by the time of activation. The process will also inform Block Producers of the requirements for nodes to upgrade nodeos to v1.8.x from v1.7.x and earlier, and it can help them decide on an appropriate deadline to be given as notice to stakeholders of the network for when the first feature will be activated.Stay ConnectedIf you are interested in providing feedback and working more closely with our team to improve EOSIO for developers, you can send our developer relations team an email at developers@block.one.You can also keep up to date with future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be continually improving the usability of the software for EOSIO developers as we continue laying a foundation for the mass adoption of blockchain technology.Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate. Any person using or offering this software in connection with providing software, goods or services to third parties shall advise such third parties of these license terms, disclaimers and exclusions of liability. Block.one, EOSIO, EOSIO Labs, EOS, the heptahedron and associated logos are trademarks of Block.one. All other trademarks referenced herein are the property of their respective owners.EOSIO™ Version 1.8.0-rc1: was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 04. 30

A Passwordless Future: Buil...

Replacing passwords with private keys in an easy to understand metaphorWith the introduction of the EOSIO Labs™ initiative, we have begun innovating in the open with regards to the future of blockchain technologies built on EOSIO. Our first release under this initiative explores the future of private key management and its implications on security and key management — the Universal Authenticator Library (UAL). What underlies the philosophy of this release is an exploration into a larger problem, one that is centered on how passwords and authentication have been implemented across the internet, blockchain or otherwise. While there is no software release accompanying this post, this article aims to discuss problems that plague existing authentication systems, and the modern attempts to move beyond passwords attendant to such problems. We will then propose, in abstract, a new model using the metaphor of a “pass”, such as an airline ticket or a library card, to address these problems in a secure and usable way.The Hearsay ProblemCurrent methods of authenticating users suffer from what we will call “The Hearsay Problem”. Hearsay is any information received from one party about the statements or actions of a second party that cannot be adequately substantiated. Our stance is that all information sourced from systems which rely on current state-of-the-art methods of authenticating users would qualify as mere hearsay if any of the involved parties were to call the validity of the information into question.To illustrate, imagine a poorly received social media post allegedly authored by a well-known politician that threatens to destroy said politician’s career. How do we know for sure that the politician did, in fact, author the damning post? While the author could indeed have been the politician in question, it could equally be anyone with access to the politician’s social media account. To extend this reasoning, the pool of possible ‘authors’ could include any number of people close to the politician, or adversarial hackers in a targeted attack. Yet no one, including the politician and the social media service provider, would be able to present conclusive, non-circumstantial evidence that the politician was or was not definitively the author of the post in question.To use legal and technical terminology, this characteristic is referred to as repudiability, and it is not a desired trait. Two primary factors lead to this characteristic of repudiability in our social media example above; the first factor is an authentication scheme that requires disclosure of a secret in order to validate the possession of that secret. In security schemes (like passwords) that are subject to this factor, it is impossible to create logs of user activity that are verifiable by anyone other than the party and the counterparty. The second factor is the lack of means to prove that the data within a system that actually represents the intent of the user, which leads us to another problem we are calling, “The Blank Check”.The Blank Check ProblemThe Blank Check problem is present in any system that can take action on behalf of the user without needing the user’s explicit consent on that specific action. It is also present if the means of capturing the user’s consent is anything short of a log of proof that the user was informed of the implications of every individual action and explicitly consented to each action.In the example above, this problem adds the social media service itself as well as many of its employees to the list of parties that could have posted the damning post. How can we prove that the social media service or one of its employees did not have compromising access to “post” on behalf of the politician? A higher-stakes example of this problem that showcases the appropriateness for the name “The Blank Check Problem” is that of a bank account. Technologically speaking, there is nothing to prevent your bank from liquidating or locking your funds, and there would be no means of proving any wrong-doing, as the Bank could fabricate records of seemingly legitimate transactions. This would no doubt pose grave consequences that affect many stakeholders in a material way.The ‘Two Become One’An astute observer might have noticed that these problems are really two outcomes of the same underlying problem: the lack of provable audit logs. While there are technologies that do address this fundamental shortcoming in our current systems, like certificate-based systems based on asymmetric cryptography, they have yet to achieve a level of user-friendliness that makes them accessible to the general public. By addressing this challenge with easy-to-understand metaphors for a theoretical solution we will present below, we have the opportunity to improve the security and usability of all of our systems, for every kind of user, and improve users’ experience in the process.PasswordsWhen discussing cybersecurity, two basic terms should be defined: ‘authentication’, which is the process by which a user proves that they are who they say they are by possession of particular identifying credentials, typically with a username and password; and ‘authorization’, which is the process by which a user’s actions within a software platform are allowed or restricted according to their identity.Since the 1960s, passwords have been the de facto method that allows a user to authenticate themselves to a device or service. Password authentication is, by now, a well-understood technology for engineers. For users, passwords have become a simple concept to grasp; they are comfortable and familiar even for non-technical users. But while their simplicity and familiarity are a strength, passwords suffer from many weaknesses as well.Such weaknesses are both technological and human in nature. Some of them have been widely discussed, including in exhaustive detail in the NIST Digital Identity Guidelines, so we will be not be repeating them here. What is important to remember, however, is that passwords do not enable trustworthy auditable logs of the actions that a user has authorized. To authenticate with a password, it must be revealed, and in order to check the validity of a user’s password, service providers must have stored them in some form of centralized infrastructure. This means that no one but the service provider can have confidence that any audit logs they keep are accurate representations of a user’s actions. For this reason, systems that rely on passwords for authentication are subject to both The Hearsay Problem and The Blank Check Problem as described above.Modern attempts to improve or replace passwordsThere have been several attempts over the years to incrementally improve or replace passwords. Below we will review a few of the most successful cases along with their strengths and weaknesses.Password ManagersThe existence of Password Managers represents an admission of several of the fundamental flaws of passwords. They attempt to improve the situation by freeing the user from having to generate and remember sufficiently complex passwords, thus allowing for single purpose passwords that meet a much higher level of security rigor.Used correctly, Password Managers do improve security, and to a limited extent, the usability of systems with password-based authentication. Yet anyone who has tried to teach their parents, children, or non-technical friends to use today’s iterations of password manager software is painfully aware that they are neither widely adopted nor usable enough to become so.From a technical perspective, there are no standards for password managers. They attempt to guess when a user is creating an account, logging in, or updating their password to be more convenient, but they often fail. They provide the basis for an improved solution, but ultimately, they are still just passwords and are still subject to both The Hearsay Problem and The Blank Check Problem.Two Factor AuthenticationIn recognition of the weakness of passwords, attempts have been made to layer on additional security to ensure that the password itself is not the single point of failure. This approach is usually called a second factor, or two-factor authentication (2FA). There are a variety of implementations of 2FA, and while all of them do add differing degrees of incremental security to password-based authentication systems, they make up for it with added complexity in terms of setup and end-user operation. A common 2FA solution relies on SMS messages to provide time-based one-time passwords (OTP). Much like passwords themselves, two-factor solutions suffer from the problem that they are not auditable and are vulnerable to the security practices of phone carriers which deliver SMS messages to your device.This lack of provable auditability means that 2FA still does not solve The Hearsay Problem or The Blank Check Problem.The WebAuthn StandardWebAuthn is a new authentication standard proposed by The World Wide Web Consortium (W3C), an international community of member organizations, a full-time staff, and the public work together to develop Web standards. WebAuthn comes very close to solving all of these problems for Web-based transactions by using asymmetric cryptography, instead of passwords, providing one of the necessary ingredients for overcoming the problems we have outlined. However, in order to prevent users who lose their devices from being locked out of every service, WebAuthn is designed to be used in conjunction with passwords, rather than as a replacement.Another significant important limitation of WebAuthn is that it was designed as a proof of presence, not as a proof of consent. It is not defined to allow per-transaction authorization requests that are auditable by peers. So once again, systems that rely on WebAuthn don’t have provable audit logs and are subject to both The Hearsay Problem and The Blank Check problem.Blockchain as a Potential SolutionBlockchains have popularized the idea of authenticating the user for every action they authorize, using public key cryptographic signing of transactions to accomplish this goal. This is a big improvement on passwords and a step beyond what WebAuthn can provide. It also satisfies the first factor necessary to address The Hearsay Problem: provable auditability.Unfortunately, today’s blockchain user interfaces also do not define a standard for describing authorization requests in a human-friendly way to users so that they can be displayed in a trustworthy context for user approval. Without this human-friendly request rendering standard, users cannot know what they are agreeing to. This means that even though blockchains create a provable auditable log, they lack the means to prove that the data within a system actually represents the intent of the user. Thus, they are still subject to the Hearsay and Blank Check problems.Back to our social media example, if a social media platform was built on a blockchain, they would be able to prove that the politician in question did, in fact, sign the action that resulted in the post, but they would be unable to prove that they (or another party) didn’t trick the politician into signing the action by misrepresenting it.A Theoretical Solution: “Passes” instead of Keys or PasswordsTo advance the security of our systems, we need proof of user consent, combined with a level of simplicity and usability that exceeds even passwords. This means we must communicate complex technologies like asymmetric cryptography through a metaphor that is immediately understandable for every kind of user, not just technologists. One concept that meets these criteria is that of a “pass”. In describing the concept of a pass, we will show how this theoretical solution of a pass used in a Pass Manager Application can satisfy both The Hearsay Problem and The Blank Check Problem we have outlined.For users, a pass represents a familiar and tangible means of proving possession of a credential. Every day we interact with physical passes as part of our daily routines. As a library user, you simply show up and present your library card. As an airline passenger, you simply show up and present your ticket. These are examples of single-purpose passes, for services that do not provide a single-purpose pass, you might present your Driver’s License to prove your identity.To support authentication and authorization use cases, we introduce the concept of the digital “Pass Manager”. A Pass Manager is a passwordless paradigm for registration, authentication, and authorization use cases.What could you do with a Pass Manager?Issuance and RevocationService Providers could request the Pass Manager to issue a new pass for a user.Users could organize their passes into groups. (e.g. my work passes, and my personal passes)Users could authorize and deauthorize passes across multiple devices.AuthenticationService Providers could request proof of a user’s possession of a pass.Users could provide proof of their possession of a pass.AuthorizationService Providers could request proof of a user’s authorization to perform a particular action, on the authority of a pass the user possesses.Users could see authorization requests rendered clearly in a human-friendly way, and choose whether to authorize the action, on the authority of a pass they possess.How would a Pass Manager work?A Pass Manager implements a (yet-to-be-defined) standardized protocol for issuance and revocation of passes, authentication, and authorization with passes. A Pass is a conceptual abstraction that encapsulates credential info (keys).The experience of using a digital Pass Manager should be very similar to the physical analog of pass cards. The user simply arrives at a service (whether it is a web app, a native app, a point of sale system, or a kiosk), and presents a pass to sign in or authorize an action. This is like a college student using their College ID to gain admission to a collegiate sports event, then once inside, using it to buy food at a stand with their campus dining balance, being presented with order confirmations before committing to the transactions.Under the hood, a blend of technologies can work in tandem to produce superior security and usability for users, including cryptographic signing, hardware keys, and biometrics for credential security, as well as a transport-agnostic protocol for portability.Anytime a user’s consent is sought by a Pass Manager, human-friendly descriptions of the action should be shown to the user, and that description (or a cryptographically verifiable derivative of it) should be included in the signed response from the Pass Manager. The use of keys means that logs are non-repudiable and can be verified by third parties, and the inclusion of the human-friendly description in the signed response can serve as proof of the user’s intent. These characteristics solve both the Hearsay and Blank Check problems.This model can support both current web technology and future blockchain technology use cases. It is also capable of providing a clear user experience for both login and authorization use cases.What is necessary to make Pass Managers successful?InteroperabilityFirst and foremost, a Pass Manager protocol should be built to allow users the freedom to choose a Pass Manager that best suits their needs. This is important because it prevents vendor lock-in, creating the free market that is necessary to foster innovation in both security and user experience. This way, the best user experience with acceptable security will win.To provide this freedom of choice, there will need to be standard protocols for signup, login, and authorization. Authorization, in particular, is an interesting challenge, because it requires the definition of a standard for describing requests for authorization to users in a way that is understandable, auditable, provable, and portable.PortabilitySecondly, the Pass Manager protocol should be built for portability; meaning: 1) support for every kind of application or service running on any platform, 2) support for limited or no network connectivity, 3) support for multiple devices, and 4) support for cross-device communication.Users have desktop computers, laptop computers, phones, tablets, smart watches, and USB keys. So a simple and seamless experience for issuing and revoking pass access across multiple devices is critical. Users also interact with point of sale systems, untrusted public computers, vending machines, and kiosks. So the ability to interact from one device to another, with or without network connectivity, without needing the devices to trust each other is necessary.These requirements can be met by defining the Pass Manager protocol to be transport agnostic. This means that the protocol should focus on defining the nouns and verbs that implementing systems must be able to fluently speak, and allow the transports through which they are spoken to vary. Examples of transports might include custom protocol URLs, Apple Universal Links, Android Intents, server requests, QR codes, Bluetooth, NFC, and JavaScript APIs. With this flexibility, Pass Managers can be truly portable.UsabilityUsers should not have to consider the implications of whether they are using a web service with a database backend or a blockchain system. In the case of blockchain, they should not have to know what blockchain platform or network the application they are using is built on. They should only need to consider their use case. Things like…“I’m withdrawing funds from an ATM.”“I’m logging into my email.”“I’m liking a post on social media.”“I’m buying chips from a vending machine.”“I’m transferring 100 tokens from Dan to Brian.”Never things like…“I’m signing a transaction, with an R1 key, authorized for my blockchain11 account, on the example.com dapp, which is built on the Telos blockchain, which is built on the EOSIO platform.”SafetyCurrent implementations of both passwords and public key systems are unsafe for a variety of reasons. Pass Managers must do better.In order to protect users from attacks on centralized honeypots of credentials, secret credential data should never be stored on centralized infrastructure in any form (hashing and salting is not good enough). In order to protect users from having their credentials stolen through phishing, malware, and man-in-the-middle attacks, users should never actually know what their credentials are, and they should never be entered manually or automatically into any service. In order to protect users from being tricked into adding malicious passes, users should not be able to add or remove passes themselves. Instead, a trusted Pass Manager should handle this automatically on behalf of the user in response to the user visiting new services or getting new devices.The Future is Wide Open for Pass ManagersIn this article, we have laid out problems to be solved to address security and usability concerns with current state-of-the-art methods for securing user accounts. We have presented the concept of Passes replacing passwords and the digital Pass Manager as a means of solving these problems. We have discussed the necessary attributes for a Pass Manager protocol to succeed, but we have not explicitly defined the protocol. We encourage enterprising developers to solve the problems that plague both password and key-based security systems and to consider the Pass metaphor as one way to accomplish that goal.All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate. Any person using or offering this software in connection with providing software, goods or services to third parties shall advise such third parties of these license terms, disclaimers and exclusions of liability.A Passwordless Future: Building Towards More Secure and Usable Authentication Systems was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 04. 17

EOSIO Software Release: Ric...

Cultivating User Understanding with Richly Rendered Ricardian ContractsA critical component of user security is preventing phishing attacks or bait and switch attacks which trick users into agreeing to something that isn’t actually going to happen as a result of their agreement. In blockchain, this can occur when a website or application indicates to a user that they are approving one action, but present a different transaction to the key management application (i.e. Authenticator or wallet). The website says one thing, but issues something else to the blockchain. For example, a user may be lead to believe they are sending a small number of tokens to an exchange, but in actuality, they are sending all of their tokens to a thief.A pillar of EOSIO’s usability since its dawn has been support for defining Ricardian Contracts that are paired with Smart Contracts to serve as human readable representations of an action’s intent in plain english for any user (not developer) to understand. The intent of code being transparent and auditable comes into play as blockchain actions are often irreversible. We’ve published on the power of this concept before in Dan Larimer’s past articles on the intent of code as law and the effect this has on user experience and security. Before Ricardian Contracts, it was near impossible for an average user to understand or be expected to understand exactly what actions they were signing in a Smart Contract. Existing Authenticators (wallets) that present transactions to users for signing with their private keys are often not equipped to render Ricardian Contracts in a way that cultivates understanding, so, current solutions rely on applications to explain to the user what a smart contract says on the front end without any auditable association to the actions taking place on the blockchain.Ricardian Contract ReleasesToday’s release introduces two new features for Ricardian Contracts to create consistency and transparency in how Ricardian Contract data is presented to users in Authenticators which ask them to sign transactions. The Ricardian Contract Specification defines a template language based on JSON for adding metadata, a subset of Markdown/CommonMark for formatting, and Handlebars for variable substitution. Smart Contract developers can follow the specification to richly format Ricardian Contracts to cultivate understanding for their users.In addition, we built the Ricardian Template Toolkit, an implementation of a renderer for the Ricardian Contract Specification that demonstrates how Ricardian Contracts built to the new specification can be displayed. This Template Toolkit can be used by Authenticator developers to consistently render Ricardian Contracts and by Smart Contract developers as an authoring and testing tool.As an illustrative analogy, one could think of the Ricardian Contract Specification like the HTML specification and the Ricardian Template Toolkit like a browser that can render documents that follow the HTML specification.For EOSIO Blockchain Users, the Ricardian Contract Specification and the Ricardian Template Toolkit projects enable a clear understanding of the agreements to which they are consenting. We encourage Smart Contract Developers to enhance their Smart Contracts by following the Ricardian Contract Specification, and Authenticator developers to adopt the Ricardian Template Toolkit to provide a much clearer rendering to users of what will happen when they approve a blockchain action.Stay ConnectedIf you are interested in providing feedback and working more closely with our team to improve the EOSIO for developers, you can send our developer relations team an email at developers@block.one.You can also keep up to date with future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be continually improving the usability of the software for EOSIO developers as we continue laying a foundation for the mass adoption of blockchain technology.All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate. Any person using or offering this software in connection with providing software, goods or services to third parties shall advise such third parties of these license terms, disclaimers and exclusions of liability.EOSIO Software Release: Ricardian Contract Specifications and the Ricardian Template Toolkit was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 04. 12

EOSIO Labs™ Release: The Un...

EOSIO Labs™ Release: The Universal Authenticator Library (UAL) — Increasing the Accessibility of Blockchain ApplicationsIn conjunction with the announcement of EOSIO Labs™, Block.one has released the Universal Authenticator Library (UAL) repository to explore the future of private key management. UAL is a first step towards our explorations in the wallet ecosystem, an opportunity for both Block.one and others in the EOSIO developer community to collaboratively push the boundaries of what is possible within the industry and the EOSIO™ software. As with all releases of EOSIO Labs, we welcome and encourage your feedback in shaping the future of this repository.Within the EOSIO wallet ecosystem, our interest has been focused on the direction of key and password management. In the realm of blockchain technology, wallets serve a critical role in authenticating users who interact with blockchain applications. To that end, the term ‘wallet’ is potentially misleading if the user’s intention was to ‘authenticate’ with a service or to ‘sign’ a transaction. Since traditional wallets functioned as a place to store tokens, the blockchain community adopted the term ‘wallet’ in the early stages of its development. However, as the industry focus gradually shifted towards the utility of blockchain applications, storing tokens became less of a focus compared to using applications, and more as a byproduct of utility. Cognizant of this change, we have considered a number of terms that would more accurately describe the purpose of ‘wallets,’ from ‘signature providers’ to ‘authenticators’ to ‘transaction signers’. Ultimately, we have decided that for the purposes of this library and our future literature in the wallet ecosystem, we will be referring to all ‘wallets’ as ‘authenticators’.Interactions with Authenticators Drive User ExperienceOver the last several months, we’ve been thinking a lot about how EOSIO-enabled applications interface with authenticators, and how that impacts both the developer and user experiences. There has been tremendous growth in the ‘wallet’ ecosystem. Hardware and software authenticators purposefully built for EOSIO as well as migrating to EOSIO from other blockchain and non blockchain industries have created tremendous value for blockchain application users and the ability to choose an authenticator that fits their needs.However, with an ever-increasing number of authenticators comes increasing complexity. App developers must integrate with each authenticator (or give up and choose not to), and end users face increased uncertainty — even confusion — as the user experience of signing transactions across various independently operated authenticators diverge. Users may even find that the app they want to use doesn’t work at all with their authenticator of choice.To address these issues, we’ve begun exploring interchangeable integrations for Authenticators through a universal API, the Universal Authenticator Library.Universal Authenticator LibraryThe Universal Authenticator Library (UAL) allows app developers to integrate with a variety of authenticators (wallets, app explorers, key managers, etc.) by coding to a single, universal API. It also offers developers an optional, but opinionated, UI layer so that application users get a consistent look and feel independent of the authenticator they are using or the site they are on.Once integrated, apps are able to provide their users with an experience akin to social login or single sign on with very little effort. And as more authenticators are developed, supporting them is as simple as adding a few lines of code.ArchitectureUniversal Authenticator Library consists of three main components: UAL Core, Authenticators and Renderers.UAL Core: This TypeScript library is the glue that binds these three concepts together. UAL Core defines the standard that UAL wallet authenticator plugins must conform to and exposes a consistent, public API to app developers along with additional convenience methods.Authenticators: Authenticators can be thought of as UAL wallet plugins. They wrap the individual wallet APIs in a common UAL-compatible wrapper. These are not part of the core UAL library but exist as separate codebases often written by the community or wallet developers themselves. There are currently authenticators for Scatter Desktop, Lynx, Ledger, and TokenPocket. Others can be easily written using our UAL Authenticator Walkthrough as a guide.Renderers: Renderers are optional, opinionated UI-layer plugins for UAL. For users, they are responsible for the consistent look and feel. For developers, renderers provide a familiar and idiomatic way to integrate UAL into their frontend framework or library. There are currently renderers for PlainJS and ReactJS, and we invite the community create others.User Experience will Drive AdoptionThe best way to achieve optimized wallet usability is to enable the free market to operate efficiently. Users must be able to vote for the best user experience with their choice of authenticator. This user choice will be the engine that drives rapid improvements to the blockchain user experience.A unifying tool like Universal Authenticator Library will do just that — help developers drive adoption of their applications with a simplified and familiar transaction signing experience, and reduce friction for users so that they have the freedom to use the wallet of their choice.How you can get involvedUniversal Authenticator Library is in alpha and it needs your contributions. Here are some of the ways you can get started:Check out the UAL documentation.Spin up the Basic Example App for UAL with ReactJS or Basic Example App for UAL with PlainJS and see how they work.Add UAL to your web app. You could use one of the prebuilt Renderers (UAL Renderer for PlainJS or UAL Renderer for ReactJS), but you may also integrate directly with the UAL Core API.Build a UAL authenticator for your favorite wallet and open source it.Build a UAL renderer for a different frontend library or framework (e.g., Vue.js, AngularJS) and open source it.Contribute to the UAL Core library. Help make it even better.Report issues that you may find via GitHub issues in the matching repo.Ask questions on the EOSIO StackExchange. Be sure to add a UAL tag.Stay ConnectedIf you are interested in providing feedback and working more closely with our team to improve the EOSIO Labs repositories for developers, you can send our developer relations team an email at developers@block.one.You can also keep up to date with future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be continually improving the usability of the software for EOSIO developers as we continue laying a foundation for the mass adoption of blockchain technology.All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate.EOSIO Labs™ Release: The Universal Authenticator Library (UAL) — Increasing the Accessibility of… was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 04. 03

Introducing EOSIO Labs™: A ...

At Block.one, we believe in an open innovation model that allows us and others in the EOSIO developer community to collaboratively push the boundaries of what is possible within the industry and EOSIO™ software.One area we have been actively exploring is the EOSIO wallet ecosystem and the direction of key and password management. In blockchain, wallets (as key managers) serve a critical role in the way users interact securely with blockchain applications. They are a pivotal component in the path towards mass adoption of blockchain-based software and have been a focus of much of our research.After much consideration, we have decided to release our work related to key management in a way that can be used by existing EOSIO wallets. That means Block.one itself will not be releasing a proprietary wallet at this time. Instead, we are taking this opportunity to release our work as Open Source Software, and by doing so hope to encourage ongoing improvements of the standards in the wallet ecosystem. We will be releasing this work as the first in a series of repos in a form we’re really excited to share for both Block.one and community innovation: EOSIO Labs™.We are pleased to announce the EOSIO Labs initiative. As we create new tools in the EOSIO family that impact the global community of developers, we have come to recognize the need for a clear distinction between in-house products we are committed to developing, software tools we are committed to growing, and research projects we would like to publish for feedback from others in the EOSIO community to help understand the value they can provide.EOSIO Labs Release: Universal Authenticator LibraryWith this announcement, we are open sourcing the Universal Authenticator Library (UAL) GitHub repository. This first step in the EOSIO Labs initiative demonstrates an alternative approach for app developers integrating with an Authenticator (wallets, app explorers, key managers, etc.) by coding to a single, universal API. Furthermore, it offers developers an optional, but opinionated, UI layer so that users get a consistent look and feel independent of the wallet they are using or the site they are on.As we’ve seen the EOSIO ecosystem evolve over the past year, we’ve been studying how EOSIO-enabled applications interface with wallets, and how that impacts both the developer and user experiences. There has been an explosion in the number of wallets — hardware and software — and this has given users something very valuable: innovation and choice.But with an ever-increasing number of wallets comes overhead. App developers must integrate with all of those proprietary wallet APIs (or give up and choose not to), and end users face increased uncertainty — even confusion — as transaction signing experiences multiply and diverge. Users may even find that the app they want to use doesn’t work at all with their wallet of choice leading to frustration, fragmentation, and barriers to streamlined adoption.This work illustrates our direction and thoughts, now available for the wider community to review and consider adopting in their development workflow. We welcome your feedback and will continue to explore and publish more related work in the future.Working with EOSIO Labs RepositoriesThe intent of the EOSIO Labs initiative is to more rapidly share our innovations and discoveries with all developers and by doing so increase the value these innovations can deliver to the EOSIO community at large. Open source repositories for projects published under EOSIO Labs are to be considered alpha, released with no firm expectation of future involvement by Block.one. Block.one’s continued contributions and involvement will depend on wider community adoption of such projects.EOSIO Labs repositories are experimental. Developers in the community are encouraged to use EOSIO Labs repositories (released under MIT license) as the basis for code and concepts to incorporate into their applications. Community members are also welcome to contribute and further develop these repositories. Since these repositories are not supported by Block.one, we may not provide responses to issue reports, pull requests, updates to functionality, or other requests from the community, and we encourage the community to take responsibility for these. However, depending on the adoption of concepts and codebases from within the EOSIO Labs umbrella, select repositories and concepts can graduate over time to supported status to enable such projects to move ahead rapidly. As projects graduate from EOSIO Labs, they will enjoy the support we feel is needed, as afforded to actively maintained EOSIO open source libraries such as Demux, EOSJS and others.Stay ConnectedIf you are interested in providing feedback and working more closely with our team to improve the EOSIO Labs repositories for developers, you can send our developer relations team an email at developers@block.one.You can also keep up to date with future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be continually improving the usability of the software for EOSIO developers as we continue laying a foundation for the mass adoption of blockchain technology.The Future is Open for EOSIO LabsGoing forward through EOSIO Labs, Block.one will continue releasing our thoughts and research on the direction of key and password management. This is just the first of many areas of research we hope to tackle as part of the community. We welcome and encourage your feedback on areas of interest to explore, and look forward to continually growing one of the most vibrant and innovative technology communities in the world.Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate.Introducing EOSIO Labs™: A Place for Open Innovation was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 04. 03

Analysis of Bancor Equation...

IntroductionIn this document, we describe the Bancor equations supporting REX and the reasoning behind setting the REX initial state and any possible constraints on the system. We first present the relevant REX pool balances. These balances are represented both by their C++ smart contract variable names and by the mathematical variables used in the presented equations. If not shown explicitly, the unit of all balances, paid fees and staked resources is the blockchain core token SYS. The balances aretotal_unlent represents the SYS balance that is available for renting. Inthe following we use u to represent this balance, i.e., u = total unlent.total_lent represents the total rented SYS balance. At any point in time, total lent is the sum of tokens staked in all currently open loans. In the following we use l = total lent.total_rent is a virtual balance. The initial value of this balance must be strictly positive as discussed below. The balances total_rent and total_unlent are the two connectors of the Bancor algorithm which determines CPU and Network renting prices. In the following we use f = total rent.For a detailed description of the REX smart contract, see Ref [1].REX Loan CalculationsUpon renting CPU or Network resources, the amount staked to those resources for 30 days is calculated as a function of the loan fee, ∆f, and the REX pool balances u = total_unlent and f = total_rent, using Bancor equation. For a given loan with id i, the equation isFor example, if at a given point in time, u = 5×10⁷, and f = 3×10⁴, a loan fee ∆f⁽ⁱ⁾ = 1 results in renting ∆u⁽ⁱ⁾ = 1666.6111 SYS worth of resources. That is, the renting cost rate for this loan is ∆f⁽ⁱ⁾/∆u⁽ⁱ⁾ ≈ 0.06%. In general, the REX pool balances are large compared to the fee of a given loan, then the renting cost rate can be estimated asWhen the loan described above is created, the REX pool balances are updated as follows: u → u − ∆u⁽ⁱ⁾, l → l + ∆u⁽ⁱ⁾, f → f + ∆f⁽ⁱ⁾. In other words, the staked amount ∆u⁽ⁱ⁾ is moved from u to l, i.e., from total_unlent to total_lent. In addition, the paid fee is added to total_unlent. The overall set of updates isNote that f is a virtual balance and there is no double spending by adding ∆f⁽ⁱ⁾ to both u and f.Initializing REX PoolInitially, the REX pool is empty (u = l = 0). As lenders buy REX (lend SYS tokens), u increases. On the other hand, the balance f is virtual and needs to be initialized to some value f₀. It is important to note that f₀ must not be zero; otherwise, the first loan will deplete the entire u balance no matter how small the paid fee is. This can be easily verified by setting f = 0 in Eq 1 which results in ∆u = u for any ∆f > 0. Seeing that we must have f₀ > 0, the next step is to decide a practical value of f₀. The REX pool balance u is expected to reach tens of millions of SYS tokens rather quickly . We will use the estimate u₀ = 2 × 10⁷ as a reference value. A small f₀ causes a problem similar to the one caused by f₀ = 0. For example, if f₀ = 100, a payment ∆f = 100 gives a rented stake of ∆u = 1 × 10⁷, which is half of the entire pool. The same can be repeated and most of the pool can be rented using only a small sum of fee payments. Following the first few loans, renting cost increases rapidly and becomes too high.On the other hand, setting f₀ to a large value would lead to a prohibitively high renting cost. By setting a target initial renting cost rate r₀ ≈ 0.1%, and using the u₀ reference balance, Eq 2 gives f₀ = 2 × 10⁴, which is the initial value we choose for total_rent.Loan ExpirationWhen loan i expires, the corresponding rented resources, ∆u⁽ⁱ⁾, are released,i.e., moved from total_lent back to total_unlent. The balance f is updatedby subtracting the output of the inverse equationwhere ∆u⁽ⁱ⁾ was calculated using Eq 1, and u′ and f′ are the values at loan expiration. Since these values are in general different from the values at loan creation, f′ = f and u′ = u, we have ∆f′⁽ⁱ⁾ = ∆f⁽ⁱ⁾. That is, the output of Eq 3 is different from the fee paid at loan creation. To summarize, the updates areLooking at Eq 3, we notice that if, at the time of expiration, total_unlent happens to be zero (u′ = 0), the equation gives ∆f′⁽ⁱ⁾ = f′. And following the update given by Eq 4, we get f′ = 0 after the loan expires. As described above, this leaves the market in an unstable state. One scenario that can lead to this state is as follows: while there is at least one outstanding loan, one or more REX owners may sell enough REX to cause total_unlent to drop to u′ = 0. Following that, one or more loans can expire resulting in f′ = 0. In order to prevent the system from reaching that state, we impose a dynamic lower bound on u which we describe in the following section.Unlent Balance Lower BoundLet ulb be the dynamic lower bound of u, which means that at any point in time we have u ≥ ulb. We must define ulb such that ulb > 0 as long as there are outstanding loans, and ulb = 0 when all loans have expired. The second condition allows REX owners to sell all their REX. Setting ulb to be a fraction of l, i.e., ulb = α×l, where 0 <α< 1, satisfies both requirements. In addition, we want a reasonably low ulb so that it does not routinely cause selling orders to be queued and renting actions to fail. We set α = 0.2, i.e., ulb = 0.2 × l.Note that we chose to calculate ulb as a function of l instead of f for tworeasons. First, u is expected to be of a different order of magnitude than fwhich makes the comparison impractical, and second, the value of f cannotbe used to determine whether there are outstanding loans.Adjusting REX Pool Virtual BalanceWe provide a backup solution that can be invoked in case REX initial condition is out of balance. This can happen, for example, if after a period of time, total_unlent remains well below the reference value of u₀ = 2×10⁷ described above. It means that the initial renting cost rate is well above target value r₀ ≈ 0.1%, or the target rate determined by similar resource renting markets. The action setrex allows producers to set the balance f to a predetermined value calculated using Eq 2 as f₀ ≈ r₀ × u, where u is the current value of total_unlent and r₀ is the target renting cost rate.Derivation of the EquationsBancor protocol [2] allows for instant liquidity by connecting a currency reserve to a smart token. It defines the fractional reserve ratio aswhere R is the current value of the currency reserve, S is the smart token current supply, and P is the current token price relative to the reserve currency. The protocol posits that F is always constant and is set to a predetermined value which dictates the price behavior as a function of supply.One of the results of the protocol is an equation that determines the amount to be paid in return for a given number of tokens:where R₀ is the initial reserve value, S₀ is the initial smart token supply, and ∆S is the number of issued tokens.The inverse equation,determines the number of smart tokens issued in return for a given payment. After the tokens are issued, the supply is updated to S = S₀ + ∆S and the reserve to R = R₀ + ∆R.Now consider a smart token that is connected to two reserves R⁽¹⁾and R⁽²⁾, and assume that the fractional reserve ratio of the smart token is the same for both reserves. A payment ∆R⁽¹⁾ results in ∆S issued tokens given by Eq 6 applied to R⁽¹⁾:If these tokens are then sold (equivalent to adding −∆S to the smart token supply) in exchange for the second reserve currency, we obtainReplacing Eq 7 in Eq 8 results inNote that ∆R⁽²⁾ and ∆R⁽¹⁾ have opposite signs. In REX equations shown above, the two reserves are f ≡ R⁽¹⁾ and u ≡ R⁽²⁾.References[1] REX Implementation. https://github.com/EOSIO/eosio.contracts/issues/117[2] Eyal Hertzog, Guy Benartzi, and Galia Benartzi. Bancor Protocol White Paper.All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate.Analysis of Bancor Equations Supporting REX was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 03. 29

EOSIO.contracts Version 1.6.0:

EOSIO.contracts Version 1.6.0: Scaling Accessibility of Network Resources through a Resource Exchange (REX)As a contributor to the development and enhancement of the EOSIO™ software, we are pleased to confirm that a stable release is available for EOSIO.contracts. For a full list of updates made in this release, please refer to the Summary of Changes in EOSIO.contracts v1.6.0 in detail on Github and the description in issue (#117). This release focuses primarily on issues related to REX (#94, #182, #196, and #208).The intention of The Resource Exchange (REX) functionality is to enable token holders to rent portions of their CPU and Network resources to those needing more computational power to operate applications on the platform. In this release, we focus on what we believe to be a more robust functionality for the contracts supporting REX for the community to review, adapt, and build on.Interested users can review the Bancor equations that were used to support REX and the possible choices for initializing the system. An overview of these considerations will be detailed further in an article forthcoming by Block.one engineers who have been working on these issues.Allocation of Network Resources through an ExchangeThe functionality provided in this release for REX-related contracts are provided within the eosio.system contract without corresponding user interfaces and deployment choices. REX contract code provided is not a product in and of itself, but is intended as a baseline for contracts that developers can utilize to create exchange products that enable this functionality for users of EOSIO-based blockchains.As such, REX provides contracts for a CPU and Network resource rental marketplace in which holders of the core token of the blockchain can lend portions of their existing resource allocations by buying (lending resources) and selling (un-lending resources) REX tokens into the REX pool.Blockchain application developers can rent CPU and Network resources from the REX pool to meet their resource needs. The duration of each loan, as designed, is 30 days and the loan price is determined by an automated market maker. Note that a REX token is not tradable, it is merely a convenient accounting unit and helps determine the return rate available to REX holders as determined by the level of rental activity. Optionally, proceeds from RAM trading fees and account name auctions can also be channeled to the REX pool, thus providing an additional source of return to REX holders.One byproduct of the way REX contracts have been developed is that it has the potential to increase voter engagement on public EOSIO-based blockchains. Core token holders are only allowed to participate in the REX pool (earning tokens for renting their available resources) only after having voted for at least 21 Block Producers or having delegated their votes to a proxy.Channeling system fees to REXThe source code of the eosio.system contract is by default set up to channel the account name auction fees and the fees collected from buying and selling RAM to the REX pool. The channeling of these fees only occurs for new fees collected; it does not impact any of the funds already collected in the `eosio.ramfee` and `eosio.names` accounts.The channeling of these fees can be disabled in the source code by setting the `CHANNEL_RAM_AND_NAMEBID_FEES_TO_REX` macro (defined in `eosio.system.hpp`) to 0.Deploying REX in your EnvironmentThe REX introduces new setup requirements for initializing the system contract.The account eosio.rex must now be created in addition to all the other existing system accounts prior to deploying the new system contract eosio.rex must not be a privileged account.The `eosio::init action`, which is only needed when deploying the system contract to a blockchain for the first time, was introduced in v1.4.0 of EOSIO.contracts. In this release, it has further been modified to send an inline `eosio.token::open` action to open a zero-balance entry corresponding to the core token symbol for the `eosio.rex` account. The `eosio.token::open` action was first introduced to the `eosio.token` contract in v1.3.0 of eosio.contracts. It is recommended to deploy a recent version of the token contract (at a minimum version 1.3.1) to the `eosio.token` account prior to deploying the new system contract. If an older version of the token contract is deployed, the `eosio::init` action will still succeed, however when the inline `eosio.token::open` action executes it may do nothing.If this version of the system contract is replacing an existing deployment of an older version of the eosio.system contract, then no `eosio::init` action is necessary or even allowed. Block Producers can optionally execute the `eosio.token::open` action to create the zero-balance entry to the core token symbol for the `eosio.rex` account.ABI file `rex.results.abi` (generated automatically) needs to be deployed on account `eosio.rex`. The corresponding contract `rex.results.wasm` must NOT be deployed. The actions `buyresult`, `sellresult`, `rentresult`, and `orderresult` of `rex.results` are all no-ops. They are added as inline convenience actions to `rentnet`, `rentcpu`, `buyrex`, `unstaketorex`, and `sellrex`. An inline convenience action does not have any effect, however, its data includes the result of the parent action and appears in its trace.Adjusting the REX Pool Virtual BalanceAction setrex allows Block Producers to reset the `total_rent` balance of the REX pool to a given value, if the need arises. It is important to note that this action is NOT required to initialize the REX system and is not recommended to be used more than once. It is a backup mechanism that allows Block Producers to balance the renting market prices in case the initial settings were impractical and not in line with the amount of tokens lent to REX. `total_rent` is a virtual balance and no real tokens will be added or removed in this action.Stay ConnectedIf you are interested in providing feedback and working more closely with our team to improve the EOSIO software for developers, you can send our developer relations team an email at developers@block.one.You can also keep up to date with future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be continually improving the usability of the software for EOSIO developers as we continue laying a foundation for the mass adoption of blockchain technology.All product and company names are trademarksTM or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.DisclaimerBlock.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate.EOSIO.contracts Version 1.6.0: was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 03. 29

#BuiltOnEOSIO: Effect.AI

#BuiltOnEOSIO: Effect.AI is Affecting the Way We Build, Monetize, and Power Artificial Intelligence — For the BetterSince the legendary Go match between AlphaGo and Lee Sedol in 2016, when Google’s DeepMind product beat the 18-time world champion — marking the first time a computer beats a 9-dan professional, the world has been all the more captivated by the power of artificial intelligence. At once fascinating and formidable, machine learning has the potential to radically change human lives for the better, whether it be through aspects such as natural language processing, bioinformatics, or credit card fraud detection. For its many obvious benefits, however, AI technology has yet to see mass adoption by businesses across the board. In fact, only 21 percent of enterprises surveyed in a McKinsey report say that they have incorporated AI in parts of their business, mostly in areas such as service operations and product development. Among the top ranked reasons for this include a lack of AI talent and a lack of technological infrastructure to support AI implementation. So far, only the big players in the tech space have been able to develop solid go-to-market AI solutions, with the gamut not extending much further beyond Amazon’s Alexa, Google’s TensorFlow, and Apple’s Siri.https://medium.com/media/5b7f2e4c2bd9e39cc280b04a45437b74/hrefRealizing that small companies are placed at an acute disadvantage when it comes to finding quality training data to build AI algorithms, Chris Dawe and his founding team members Jesse Eisses and Lauren Verspeek decided to create a decentralized model for data annotations with the aim of helping companies kickstart their AI initiatives. With that, Effect.AI was born as “an open, democratic & decentralized network for artificial intelligence.” Specifically, the team recognized that the foundation of this network is a global microtasking workforce, one that will carry out machine learning tasks such as data annotation, sentiment analysis and survey completion — supported by a marketplace that facilitates the exchange of AI solutions and services, much like Amazon’s Mechanical Turk (MTurk). Offering a blockchain alternative to MTurk, Effect.AI helps developers build and monetize AI algorithms, all the while providing a distributed ‘global supercomputer’ that can power the GPU-heavy deep learning frameworks built on top of the TEN protocol, which is a tech stack of smart contracts and algorithms that allows anyone to build their own AI services on the network.It is indeed timely that Dawe, Eissens and Verspeek have identified this natural synergy between blockchain and artificial intelligence, given that both forms of emerging technology possess huge potential to grow global economic activity in the next three decades. AI in particular is forecasted to deliver an additional USD 13 trillion to the world market by 2030, while blockchain-related services have been suggested to comprise 10 percent of global GDP by 2027. Blockchain is also uniquely positioned to address some of the biggest pain points in AI adoption at present: by allowing for the decentralized ownership of and access to AI, blockchain networks can open up new pools of large annotated datasets, as well as help power the complex technical infrastructure needed for AI implementation with distributed computation, both of which are aspects that have thus far given the likes of GAFA a monopolistic edge over AI development. For example, because there is no middleman involved in the decentralized microtasking platform (called ‘Effect Force’), its registered workers can receive instant payment from service requesters, who will in turn receive AI algorithms and solutions for a way lower price than if they were to engage Amazon, Google or Apple for AI services.And over the span of just 18 months, more than 2 million data annotations have already been performed on the Effect Network, some of which are for companies working with NLP (e.g. chatbots, translations, sentiment analysis) and computer vision (e.g. automotive, image tagging). Having partnered with the United Nations and the Government of Singapore on several pilot projects, the Effect.AI team also has big, bold plans to make a global impact. In collaboration with the UN, they are now setting up a social impact hub in Georgia, which aims to “provide jobs to those [in developing countries] who need them (by enlisting local workers for the microtasking ‘Effect Force’ platform), allowing them to educate themselves and work on something that has meaning and impact”. According to Effect.AI’s January newsletter, one of the goals of this collaboration is to encourage the UN to “use Effect Force to enrich and structure data to solve pressing issues in Georgia, like disaster/flooding prediction and relief, sustainable living, and other matters the UN are closely monitoring in the region”. In a similar vein, ‘Effect Force’ is providing Singapore’s Info-communications Media Development Authority (IMDA) with the required labor for a geo-mapping project, which would entail “Effect Force workers identifying and categorizing geographic details from satellite images”. As such, these initiatives show that a decentralized, blockchain-based AI system has the power to accelerate developments in humanitarian aid and government.On 21 February 2019, Effect.AI made a landmark decision to officially switch from the NEO protocol to EOSIO. Given the considerable costs that would have been involved in any strategic change, what motivated the team to nonetheless go ahead with the move? “It’s simple, building a network as complex as ours just does not work on NEO at the moment,” said Dawe. “The EOS blockchain, on the other hand, provides us with a more robust alternative, with its clearly scalable infrastructure, ability to easily iterate upon, speed, security, high TPS, and of course, its incredible community.”Having participated in Block.one’s 2018 EOS London Hackathon as mentors, the founding team found the support to be overwhelming. “We felt the powerful strength and positivity of the EOS community [at the hackathon], and the experience solidified our decision to build on EOSIO,” added Dawe. “When we officially announced the migration of our project to EOSIO, the community response was unreal. We must have received over 200 messages from EOS developers and community members welcoming us and offering their support.” And as well they should, since the Effect.AI team is clearly working towards a worthy and innovative cause of making artificial intelligence more accessible to the world through blockchain infrastructure, whether it be for technologists, businesses or governments.More information on Effect.AI available on https://effect.aiStay tuned to our EOSIO Spotlight series where we’ll highlight some of the truly exceptional projects being built on our platform. If you have a project you’d like to share with us, please email spotlight@block.one.-Developer Relations teamDisclaimerBlock.one is a software company that is producing the EOSIO software as a free, open-source protocol. This software may, among other things, enable those who deploy it to launch a blockchain, or decentralized applications with various features. For more information, please visit https://github.com/eosio. Block.one does not provide financial support to anyone seeking to become a block producer on any version of the EOSIO platform that may be adopted or implemented.Block.one will not be launching any of the initial public blockchains based on the EOSIO software. It will be the sole responsibility of third parties, the community, and/or those who wish to become block producers, to adopt and implement EOSIO in the manner they choose, with the features they choose, and/or providing the services they choose. Block.one does not guarantee that anyone will adopt or implement such features, or provide such services, or that the EOSIO software will be adopted and implemented in any way.Block.one does not endorse any third party or its products or services, even if they are mentioned herein. Block.one is not responsible for any linked content or content provided by third parties, whether used directly or incorporated into this document.Please note that the statements herein are an expression of Block.one’s vision, not a guarantee of anything. While we will try to make that vision come true, all aspects of it are subject to change in all respects at Block.one’s sole discretion. We call these “forward looking statements”, which includes statements in this document, other than statements of historical facts, such as statements regarding Block.one’s business strategy, plans, prospects, developments and objectives. These statements are only predictions and reflect Block.one’s current beliefs and expectations with respect to future events; they are based on assumptions and are subject to risk, uncertainties and change at any time.We operate in a rapidly changing environment. New risks emerge from time to time. Given these risks and uncertainties, you are cautioned not to rely on these forward-looking statements. Actual results, performance or events may differ materially from what is predicted in the forward-looking statements. Some of the factors that could cause actual results, performance or events to differ materially from the forward-looking statements include, without limitation: market volatility; continued availability of capital, financing and personnel; product acceptance; the commercial success of any new products or technologies; competition; government regulation and laws; and general economic, market or business conditions.All statements are valid only as of the date of first posting and Block.one is under no obligation to, and expressly disclaims any obligation to, update or alter any statements, whether as a result of new information, subsequent events or otherwise. Nothing herein constitutes technological, financial, investment, legal or other advice, either in general or with regard to any particular situation or implementation. Please consult with experts in appropriate areas before implementing or utilizing anything contained in this document.The ideas and information expressed herein are solely those of the author and do not necessarily reflect the positions, views or advice of Block.one or any other employee of Block.one.#BuiltOnEOSIO: Effect.AI was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 03. 19

EOSIO Version 1.7.0:

EOSIO Version 1.7.0: Enhancements in Peer to Peer Level Communication and Real Time Transaction ThroughputAs a contributor to the development and enhancement of the EOSIO software, we are pleased to confirm a stable release is available for EOSIO. You can find more detail about EOSIO v1.7.0 in the GitHub repository. Documentation, as always, is updated on the EOSIO Developer Portal.In order to make our contribution, we are actively engaged in how businesses are building applications on the EOSIO software, and we are continually making proposals to improve the developer experience with EOSIO.Highlights in EOSIO v1.7.0P2P Networking & Real Time Transaction ThroughputAlong with our goal in keeping EOSIO among the fastest protocols on the market, our development efforts in this release are focused on improving the peer-to-peer level communication between nodes operating on the EOSIO software and real-time transaction throughput. This release improves performance by creating a priority queue for the main application thread that assigns high priority for block production and block propagation, all the while relegating transaction processing (#6577) to a lower priority. Additionally, multithreading support for net_plugin (#6725) and http_plugin (#6687) also contributes to improved performance.RPC API Enhancements (#6572)A new method that has been added to the RPC API is get_supported_apis that allows applications like wallets to discover the current set of activated plugins on an API server. This allows for a better customized user experience that can reflect the capabilities provided by the API server to the wallet.REX Support In cleos (#6785)This update adds cleos support for REX-related actions by creating the cleos system rex subcommand and associated sub-subcommands that correspond to different actions.Improved Default Value Handling (#6620)This update improves the way default values for settings in config.ini are handled and enables the code to specify appropriate values for defaults, unless the user had previously explicitly overrode the default values in config.ini.There have been changes in dependencies and libraries deprecated in this release. A full list of issues for EOSIO v1.7.0 can be found in the GitHub repository.Community Developer SupportIn addition to our growing team at Block.one, we would like to send special thanks to a few community contributors who have submitted patches for this release. We are grateful for your contributions and commitment to the growth of the EOSIO software:@coderobe@conr2d@xtuc@EvertonMelo@baegjae@huangminghuang@bspark8@kesar@firesWu@v-guGoing ForwardRelease CandidatesA brief reminder that new versions of EOSIO will be marked as ‘Release Candidates’ (-rc) when ready for first compiled release to allow for more thorough testing and documentation. After a few cycles of feedback and the completion of documentation, the release will be promoted to ‘stable’. In the case of v1.7.0-rc2, we have named it v1.7.0 and merged it into master on the GitHub repository.Stay ConnectedIf you are interested in providing feedback and working more closely with our team to improve the EOSIO software for developers, you can send our developer relations team an email at developers@block.one.You can also keep up to date with future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be continually improving the usability of the software for EOSIO developers as we continue laying a foundation for the mass adoption of blockchain technology.Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any applications related thereto. We make no representation, warranty, guarantee or undertaking in respect of the releases described herein, the related GitHub release, the EOSIO software or any documentation related to any of the foregoing, whether expressed or implied, and disclaim all liability that may arise from any use of the software or documentation for any purpose. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one.EOSIO Version 1.7.0: was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 03. 14

EOSIO Toolkit Update: Demux...

EOSIO Toolkit Update: Demux v4.0 — New RestAPI, Triggering Effect Confirmations, and more EOSIO Action SupportAs a contributor to the development and enhancement of the EOSIO software, we are pleased to confirm a new stable release for Demux, v4.0 which greatly expands the features available in the library to developers building on EOSIO. You can find more detail about Demux in its GitHub repository.One of the primary benefits of building on the EOSIO blockchain platform is the ability to create more usable, scalable, and flexible applications. While blockchain development can be difficult, one of the primary reasons developers are migrating to the EOSIO blockchain platform is its ease of use and parallels to familiar development practices used in non blockchain development. Examples of this include familiar smart contract development languages like C++, flexible permissions systems, and a number of tools in development like EOSIO.CDT and Demux.What is Demux?In July last year, shortly after the release of EOSIO, we announced Demux, a new open-source development tool for the EOSIO community that simplifies complex blockchain application development.If you aren’t already familiar, Demux is an open source library that provides a suggested architecture for creating a deterministic database off-chain that is verified by an EOSIO blockchain implementation. It draws inspiration from Facebook’s Flux Architecture pattern and Redux, creating a back-end infrastructure pattern for sourcing blockchain events in order to deterministically update queryable databases for applications built on the EOSIO blockchain.This is incredibly powerful for application developers building on EOSIO because it allows you to use traditional Mongo or Postgres SQL databases in a way that makes the data stored in them verifiable by the blockchain. This practice enables the best of both worlds: the flexibility and speed of traditional databases, coupled with the trust and immutable properties of a blockchain.Demux v4.0 UpdatesThere have been a number of updates in the past few months to the Demux library since it was released, but it has reached a point where it will start having its own release cycle independent of EOSIO core. We will continue to provide updates on its release schedule similar to the updates we provide each month for EOSIO as we continue to expand and strengthen functionality for Demux.New Demux REST APIIn Demux v4.0 we’ve introduced a new REST API that makes it easier to operate demux as a standalone environment. The REST API allows applications to interact with Demux using an endpoint — giving developers the ability to start / pause their Demux instance while making updates to better handle errors and introduce new functionality in their application without having to shut down the process. Prior to this update, if you wanted to modify your demux instance, you had to stop the service from running and make updates limiting the flexibility and speed at which you can update your application.There are a number of changes you can read about in more detail in the release like the ExpressActionWatcher being used instead of the BaseActionWatcher which exposes an endpoint that allows you to start, pause, and get info about the running demux instance. We have also removed `maxHistoryLength` on AbstractActionReader — which allows for history length to be automatically optimized based on the last irreversible block. These updates make for a more robust development experience with Demux and enable new features which we will go into in more detail below.Effect Triggers on ConfirmationOne of the most useful features of Demux are Effects, the ability to trigger non blockchain actions based on things that happen with blockchain data. For example, sending an email or pushing a notification when something is written to the blockchain.While this has been always available through Effects, in Demux v4.0 we have extended this functionality to allow for Effects to be fired based on irreversible blocks, and not beforehand. Essentially the new functionality will keep a list in memory of effects that an application wants to run and when blocks become irreversible, it will execute the actions. This allows for more granular control in your development and definite confirmation that your action has been executed and written in stone on the blockchain before taking further action.A simple example of where this is useful could be seen in a token transfer application where you want to notify a user that a transfer is pending and then moments later push a second notification that the transfer is confirmed.Inline and Deferred EOSIO Actions in DemuxFinally, we have made a tighter integration with the MongoDB plugin for EOSIO using demux-js-eos that populates blocks with actions and transactions. The core of Demux is a mongo action reader that creates a deterministic off-chain database. This functionality has been extended to include inline and deferred actions.The full details of the release can be viewed in the official GitHub repository for Demux. There are a number of breaking changes to be reviewed in more detail if you are using the Demux library in your application. The example library demux-js serves as a reference NodeJS implementation of Demux architecture.Stay ConnectedIf you are interested in providing feedback and working more closely with our team to improve the EOSIO software for developers, you can send our developer relations team an email at developers@block.one.You can also stay up to date on future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be continually improving the usability of the software for EOSIO developers as we continue laying a foundation for the mass adoption of blockchain technology.DisclaimerBlock.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any applications related thereto. We make no representation, warranty, guarantee or undertaking in respect of the releases described herein and the related GitHub release or the EOSIO software, whether expressed or implied, and disclaim all liability that may arise from any use of the software for any purpose.EOSIO Toolkit Update: Demux v4.0 was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 02. 22

#BuiltOnEOSIO: EOS Knights ...

Myeongjin Shin, co-founder of EOS Knights, one of the most popular EOSIO gaming apps in the market today, speaks to us about what makes his role-playing game (RPG) so special, and why blockchain technology is uniquely suited to the infrastructure of RPGs at large.How would you describe your project?Myeongjin Shin: EOS Knights is a mobile RPG game that runs on the EOS blockchain. From the player’s perspective, it is no different from a regular RPG game, except that it runs on an EOS smart contract. Throughout the game, players can collect and craft up to 55 items, some of which include ‘Nature’, ‘Iron’, ‘Bone’, ‘Skin’ and ‘Mineral’. By crafting the items, the hero becomes stronger in the process. Players can also trade materials and items in the marketplace with EOS tokens. The game has been consistently ranked as one of the most popular applications on blockchain app analytics platforms, with more than 5000 daily active users and 200,000 daily transactions.Where did your initial idea come from?Myeongjin Shin: I have always been an avid player of RPG games such as Diablo 2 and Monster Hunter. I also heard about Bitcoin when it was still in its infancy, and the idea of it inspired me to look into its underlying technology of blockchain. Inspired to marry my old and new interests into something revolutionary, I created EOS Knights, which is essentially a blockchain version of an RPG game, complete with material collection and item-crafting features. Additionally, the possibility of trading on the marketplace requires a strong trust component in the game, which necessitates smart contract capability, as the rareness and relative value of different materials can be permanently set by the contract, instead of by a game administrator who could manipulate data in the back end. As such, these requirements make EOS Knights a perfect project to be built on the blockchain.Can you introduce your team and tell us what makes it special?Myeongjin Shin: The team behind EOS Knights is Bada Studio, which consists of myself and fellow co-founder Seonhyang Kim. Both of us are experienced in our respective fields: I have worked as a game and smart contract developer for a decade, while Seonhyang has worked as a concept art designer for five years. We have both worked at LINE, which is one of the most popular instant messaging apps in Asia, while I have worked at Naver, one of the largest IT companies in Korea. Beyond the two of us, we also have four part-time staff members who help us build servers and support our UX/UI capabilities. Besides being well-versed in game development, we are also blockchain experts, which makes us a strong team.What stage is the project at and what are your plans for scaling up?Myeongjin Shin: Since EOS Knights’ inception in August 2018, we have been adding more content to the application and fleshing out our roadmap. Ultimately, our vision is to help realize the mass adoption of blockchain through EOS Knights, as we believe that gaming apps are most likely to be the first catalyst behind the widespread use of blockchain technology. In the near future, we plan on making it possible for Facebook-certified users to create EOS accounts in the game.Why did you decide to use blockchain technology, and specifically on EOSIO?Myeongjin Shin: We appreciate blockchain for its transparency, which forms the foundation for a reliable in-game economic system. As all the gaming data is publicly available on the blockchain, it is not possible for the admin to modify players’ records at any point. This ensures that players can trust that all the digital assets and game data have been issued according to the rules set by the smart contract. From our perspective, EOSIO is the best platform to build a gaming app on, given its fast response speed, high number of transactions per second, and strong smart contract development.How has the EOS Community responded to your project?Myeongjin Shin: As seen from the popularity of EOS Knights on State of the Dapps and DappRadar, many users in the community enjoy playing our game. We have also set up language-specific user groups on Telegram and WeChat, where users have provided us with a lot of feedback and helped us improve the game. Some of them have even built stat calculators that provide us with EOS Knights game data, help calculate the drop rate, and reveal the top scored weapon. In the meantime, we will continue to refine the game and make it even more engaging for our users.Stay tuned to our EOSIO Spotlight series where we’ll highlight some of the truly exceptional projects being built on our platform. If you have a project you’d like to share with us, please email spotlight@block.one.-Developer Relations teamRead disclaimer#BuiltOnEOSIO: EOS Knights Proves Itself to be a Game-Chainger was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 02. 20

#BuiltOnEOSIO: Chestnut Pre...

First conceived and pitched at the London chapter of the EOS Global Hackathon in September 2018, ‘Chestnut’ won both 1st runner up and Best UX at the event, and went on to compete as a finalist at the Cape Town Grand Finale.In this edition of #BuiltOnEOSIO, co-founder Daniel Liebeskind tells us all about why their blockchain-harvested version of a ‘Chestnut’ is so hard to crack, how it improves user security in digital payment, and why it marks an important step towards driving the mass adoption of blockchain technology.How would you describe your project?Daniel Liebeskind: Chestnut is a permission-based smart account, which allows users to set their own rules around transactions, with an aim to prevent careless mistakes and to protect accounts from malicious attacks.Users set security parameters on their Chestnut account, such as spending limits and transaction thresholds. Should a transaction fall outside of the parameters set, the transaction would automatically be rejected by the smart contract.Down the line, we plan to offer protection against hackers, the ability to automatically split inbound payments, recurring payments, and enhanced security parameters.Where did your initial idea come from?Daniel Liebeskind: Initially, we were inspired to make use of the EOS account architecture to create an ‘if this, then that’ system. My team and I run web development shops and are freelancers in the blockchain space, so we often pay each other in cryptocurrency. We wanted to program a smart contract to handle payment splitting and disbursements automatically.When we found out that the theme of the London Hackathon was around privacy and security, we realized that the ‘if this, then that’ model could also be used to transform EOS accounts into Smart Accounts with user-set security parameters.Can you introduce your team and tell us what makes it special?Daniel Liebeskind: We are a polymathic team with expertise in web and blockchain development, design, project management, finance and law. Believe it or not, we met in the jungles of Bali, Indonesia and bonded over our shared interest in blockchain technology.What stage is the project at and what are your plans for scaling up?Daniel Liebeskind: Chestnut is ramping up the development of our platform. We have a technology roadmap, and smart contracts have already been deployed on the Jungle testnet. We expect to launch our alpha product in May 2019 and are currently expanding our team.Given that we are a security product, it is imperative for us that we get this right, so we’ll be conducting comprehensive rounds of testing and a smart contract audit before the launch.Why did you decide to use blockchain technology, and specifically on EOSIO?Daniel Liebeskind: We believe that wide-scale blockchain adoption is only going to become a reality when we make it easy, familiar, and safe for normal people to interact with dapps and sign transactions. EOSIO has a unique account architecture that is ideal for Chestnut Smart Accounts, and we believe that EOSIO is going to be the first blockchain to gain widespread adoption once we see the release of a next wave of dapps in late 2019. Chestnut is a key infrastructure project providing a pathway to join this ever-growing ecosystem.How has the EOS Community responded to your project?Daniel Liebeskind: We have been blown away by the positive response from the community, especially from developers who have said that they think “Chestnut is an absolute need”. All of the EOSIO chains have been rallying around us and supporting us with advice, resources and technical guidance. We’ve also received a lot of good questions and engagement from the wider community.More information on Chestnut available on https://www.chestnutaccounts.com/Stay tuned to our EOSIO Spotlight series where we’ll highlight some of the truly exceptional projects being built on our platform. If you have a project you’d like to share with us, please email spotlight@block.one.-Developer Relations teamRead disclaimer#BuiltOnEOSIO: Chestnut Prevents Your Digital Chest from Being Easily Cracked was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 02. 13

#BuiltOnEOSIO: Opening Up N...

Rob Behnke, co-founder of NouGit, gives Block.one a taste of decentralized and incentivized code collaboration in the form of NouGit, a platform that allows developers to contribute their code and get paid for their efforts.How would you describe your project?Rob Behnke: NouGit is a decentralized and incentivized git repository platform. We have begun building the next generation of coding collaboration. We provide core features for users to register, add and share project repos, fund job postings on projects, and pay coders who satisfy the job requirements. Our ultimate goal is to build a system that can enable many partners to build applications on top of the core system that we provide. For our first major release, we expect to optimize value and revenue capture through virtual hackathons and coding challenges.Where did your initial idea come from?Rob Behnke: We came to Block.one’s EOS Global Hackathon in San Francisco with a couple of ideas in mind, since we didn’t know exactly what the challenge would be. Back in June last year, Microsoft acquired GitHub, and what stuck with us is just how much this piece of news infuriated the open source community. So, when one of our teammates brought up the concept of a decentralized GitHub, we went straight for it. From there, we scoped out a variety of differentiating features and started building our proof of concept.Can you introduce your team and tell us what makes it special?Rob Behnke: Our team is comprised of proven leaders in different areas of business: I lead the business aspect of NouGit, having been a serial entrepreneur with two exits, while Colby, our technical lead, is a software engineer, entrepreneur and algorithmic cryptocurrency trader. Fred, our creative lead, is an UX/UI designer and front-end developer who has worked with big brands like Under Armour, Disney and Salesforce. Our product lead is Stewart, an experienced marketing executive who has worked for Sun Microsystems, Certicom, Avaya etc. Mike, our advisor, is an MIT MBA with 15+ years of experience in telecom, investment banking and blockchain.What stage is the project at and what are your plans for scaling up?Rob Behnke: While most companies start in stealth and then launch with something to show, we were announced to the world with a proof of concept from an idea hatched only two weeks earlier, and we are now already working on the alpha. We have started by personally interviewing a few dozen of our alpha sign ups, learning about their needs and wants around this product, as well as understanding what they like and dislike about existing platforms. Looking forward, we will continue building an extensive roadmap, strengthening our ‘bare bones alpha’, and hiring more developers to further this project.Why did you decide to use blockchain technology, and specifically EOSIO?Rob Behnke: We built on blockchain because our vision is to enable decentralization of information, store of value, and creation of censorship-resistant code. EOSIO revolutionized the blockchain sphere by providing high transaction throughput and grouped user permissions. Building on top of these features allows our team to build a decentralized service with the ease of use that traditional platforms provide.How has the EOS Community responded to your project?Rob Behnke: From the very early stages of NouGit, we had started receiving feedback. At the EOS Hackathon in San Francisco, several mentors mentioned they were interested in our concept, and some of them are in fact our advisors and alpha sign-ups. As we launch and continue to build feature sets, we anticipate interacting with our community even more, as open source devs are quite vocal in general (which we love!). After all, the more feedback we get, the more we will be able to build a future that is optimized towards what the market demands.Stay tuned to our EOSIO Spotlight series where we’ll highlight some of the truly exceptional projects being built on our platform. If you have a project you’d like to share with us, please email spotlight@block.one.-Developer Relations teamRead disclaimer#BuiltOnEOSIO: Opening Up New Possibilities in Collaborative Coding with NouGit was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 02. 04

Shout out to aspiring block...

Shout Out to Aspiring Blockchain Developers: Try Out Elemental Battles and Start Building Blockchain ApplicationsAs long as you can code in C++ and JavaScript, you can learn to build EOSIO appsElemental Battles is a tutorial-game which Block.one has created to inspire and on-board a new generation of blockchain developers by simplifying the learning curve for EOSIO beginners. It is a free, eight-lesson online tutorial for anyone with basic knowledge of C++ and JavaScript, building a game set in a fantasy world where players can harness the power of three elements — Wood, Water and Fire. Build the same and learn to create blockchain apps on the EOSIO platform by utilizing basic building blocks of the EOSIO codebase.How to play the gameIn the game, the aim of each move is to select a card that ‘beats’ the card selected by a computer-powered opponent. Each card corresponds to an element and has its own point value. True to the nature of a blockchain app, all tutorial and game results will be recorded on the blockchain.How to navigate the tutorialEach lesson is presented in split-screen format, with explanations on the left panel and codes reflected on the right. Key topics covered include:How to set up a development environmentHow to develop an EOSIO smart contractHow to access the blockchain and smart contract via a web-based front-endWhat you gain from the game-tutorialUltimately, by completing the eight lessons, you can build your own fully-functioning version of the Elemental Battles game — even before you get started with building your own EOSIO DAPP. Win or lose, players gain from working through the tutorials, learning about the revolutionary technology that is blockchain, and in turn, developing on the EOSIO software.Latest updatesSince its launch in October, the tutorial has been updated to use eosio.cdt instead of eosiocpp for the building process. It has also been updated to support the following versions:Docker version 17.06 or newerEOSIO version 1.6.0Eosio.cdt version 1.5.0EOSJS version 20.0.0-beta 3Get started now by visiting battles.eos.io!DisclaimerBlock.one is a software company that is producing the EOSIO software as a free, open-source protocol. This software may, among other things, enable those who deploy it to launch a blockchain, or decentralized applications with various features. For more information, please visit https://github.com/eosio. Block.one does not provide financial support to anyone seeking to become a block producer on any version of the EOSIO platform that may be adopted or implemented.Block.one will not be launching any of the initial public blockchains based on the EOSIO software. It will be the sole responsibility of third parties, the community, and/or those who wish to become block producers, to adopt and implement EOSIO in the manner they choose, with the features they choose, and/or providing the services they choose. Block.one does not guarantee that anyone will adopt or implement such features, or provide such services, or that the EOSIO software will be adopted and implemented in any way.Block.one does not endorse any third party or its products or services, even if they are mentioned herein. Block.one is not responsible for any linked content.Please note that the statements herein are an expression of Block.one’s vision, not a guarantee of anything. While we will try to make that vision come true, all aspects of it are subject to change in all respects at Block.one’s sole discretion. We call these “forward looking statements”, which includes statements in this document, other than statements of historical facts, such as statements regarding Block.one’s business strategy, plans, prospects, developments and objectives. These statements are only predictions and reflect Block.one’s current beliefs and expectations with respect to future events; they are based on assumptions and are subject to risk, uncertainties and change at any time.We operate in a rapidly changing environment. New risks emerge from time to time. Given these risks and uncertainties, you are cautioned not to rely on these forward-looking statements. Actual results, performance or events may differ materially from what is predicted in the forward-looking statements. Some of the factors that could cause actual results, performance or events to differ materially from the forward-looking statements include, without limitation: market volatility; continued availability of capital, financing and personnel; product acceptance; the commercial success of any new products or technologies; competition; government regulation and laws; and general economic, market or business conditions.All statements are valid only as of the date of first posting and Block.one is under no obligation to, and expressly disclaims any obligation to, update or alter any statements, whether as a result of new information, subsequent events or otherwise. Nothing herein constitutes technological, financial, investment, legal or other advice, either in general or with regard to any particular situation or implementation. Please consult with experts in appropriate areas before implementing or utilizing anything contained in this document.The ideas and information expressed herein are solely those of the author and do not necessarily reflect the positions, views or advice of Block.one or any other employee of Block.one.Shout out to aspiring blockchain developers: try out Elemental Battles and start building… was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 01. 24

Four Reasons Why Developers...

It has only been seven months since the launch of the EOSIO blockchain protocol published by Block.one, but today there are at least 260 projects being built on one of the newest blockchain software solutions in the market.Since EOSIO’s inception, more projects in payments, social network, healthcare, marketplace etc. have been building on the protocolIt is unclear whether this is a record in terms of adoption in blockchain, but by any objective measure it looks impressive. The obvious question is: why?The attractions of blockchain systems are well documented. They almost all offer security, immutability, traceability and no single point of failure. That much is evident.So why are people choosing EOSIO, rather than any other alternative? Indeed, why are decentralized blockchain applications built on other blockchains migrating to EOSIO?The answer seems to be in the radical improvements in speed, cost, scalability and sustainability that EOSIO offers.To date, EOSIO is the most used blockchain software in the world. All the applications that are being built on it offer services with real-world utility. And from ride-hailing to music sharing, fitness tracking to digital payment, EOSIO apps have emerged as the safer, faster and cheaper alternative. As Simon Szczepankowski, CEO of the smart contract delivery platform Buddy, commented, “EOSIO, with its ability to process thousands of transactions per second, and its minimal associated fees and confirmation times, is the best next-generation blockchain.”After analyzing feedback from developers and entrepreneurs, below are the four reasons why applications are being built on EOSIO:1) It’s scalableParticipants at the EOS Hackathon in Hong Kong were challenged to create scalable applications on EOSIOSome existing blockchain systems process transactions at an average speed of 15–20 transactions per second. This means it has only limited real world usage. For businesses that need to transact with thousands of customers simultaneously, for example, this transaction speed is insufficient. EOSIO, on the other hand, has been benchmarked to process over 4,000 transactions per second on its public blockchain, which means that it is 200 times faster than its closest competitor — and that’s just the public network. With private implementations of the EOSIO blockchain, it can achieve even higher speeds with recent software updates. For any business that needs to process thousands of transactions at any given time, having a system that works at these speeds becomes very attractive.2) It’s fastApplications built on EOSIO have much lower latency than those on other blockchain platforms. In other words, you won’t have to wait hours or even minutes to know if your email was sent, your payment was processed, or your food order actually went through. By using EOSIO apps, consumers and enterprises do not even need to know that they’re using a ‘blockchain app’; all they know is that whatever data they have inputted for any transaction is more secure but no slower than your normal, non-blockchain app. In the words of Alex Casassovici, founder of the gaming network Azarus, “With EOSIO, users can interact with the blockchain without having to know how it works.” This is key to driving mass adoption of blockchain technology, as it amplifies the unique benefit of blockchain without compromising existing conditions that all users take for granted, such as speed and convenience.3) It’s virtually freeUnlike other blockchain protocols, EOSIO offers a more favorable cost model for consumers and developers, as it eliminates the need for transaction fees. From a consumer standpoint, whereas individual users have to pay per transaction in order to use first-generation blockchain apps, EOSIO apps are free to use. From a developer standpoint, the operating cost of running an EOSIO network is akin to that of maintaining a traditional server.4) It’s greenEOS Hackathon participants planting local flora in Cape Town as part of Greenpop’s ‘Fynbos for the Future’ programOne of the most common complaints you hear about blockchain technology is just how expensive and environmentally-unfriendly it is. Indeed, a lot of blockchain platforms require a substantial amount of electricity to run the computers needed to manage the distributed database. In fact, it takes more electricity to operate the Bitcoin network than Singapore or Portugal.EOSIO is a far more sustainable solution. Contrary to other consensus mechanisms, the Delegated Proof of Stake (DPoS) model is not energy-intensive, as it enables EOSIO-based blockchain networks to use computer resources to confirm transactions more efficiently, all the while maintaining a distributed ledger that provides all the inherent advantages of blockchain. According to calculations conducted by “social enterprise block producer candidate” Genereos, EOSIO is 66,000 times more energy efficient than Bitcoin and 17,000 times more energy efficient than Ethereum.There is a reason that blockchain is being debated with such fervor and anticipation today. It heralds the next generation of technological progress, and will slowly but surely become the new rails of the internet, ultimately improving the way we conduct business, share information, and manage data.From the evidence of take up and progress being made by developers building on the EOSIO network, it seems clear that it is offering a solution to the issues of scale, cost, speed and sustainability, which has not been available before.DisclaimerBlock.one is a software company that is producing the EOSIO software as a free, open-source protocol. This software may, among other things, enable those who deploy it to launch a blockchain, or decentralized applications with various features. For more information, please visit https://github.com/eosio. Block.one does not provide financial support to anyone seeking to become a block producer on any version of the EOSIO platform that may be adopted or implemented.Block.one will not be launching any of the initial public blockchains based on the EOSIO software. It will be the sole responsibility of third parties, the community, and/or those who wish to become block producers, to adopt and implement EOSIO in the manner they choose, with the features they choose, and/or providing the services they choose. Block.one does not guarantee that anyone will adopt or implement such features, or provide such services, or that the EOSIO software will be adopted and implemented in any way.Block.one does not endorse any third party or its products or services, even if they are mentioned herein. Block.one is not responsible for any linked content.Please note that the statements herein are an expression of Block.one’s vision, not a guarantee of anything. While we will try to make that vision come true, all aspects of it are subject to change in all respects at Block.one’s sole discretion. We call these “forward looking statements”, which includes statements in this document, other than statements of historical facts, such as statements regarding Block.one’s business strategy, plans, prospects, developments and objectives. These statements are only predictions and reflect Block.one’s current beliefs and expectations with respect to future events; they are based on assumptions and are subject to risk, uncertainties and change at any time.We operate in a rapidly changing environment. New risks emerge from time to time. Given these risks and uncertainties, you are cautioned not to rely on these forward-looking statements. Actual results, performance or events may differ materially from what is predicted in the forward-looking statements. Some of the factors that could cause actual results, performance or events to differ materially from the forward-looking statements include, without limitation: market volatility; continued availability of capital, financing and personnel; product acceptance; the commercial success of any new products or technologies; competition; government regulation and laws; and general economic, market or business conditions.All statements are valid only as of the date of first posting and Block.one is under no obligation to, and expressly disclaims any obligation to, update or alter any statements, whether as a result of new information, subsequent events or otherwise. Nothing herein constitutes technological, financial, investment, legal or other advice, either in general or with regard to any particular situation or implementation. Please consult with experts in appropriate areas before implementing or utilizing anything contained in this document.The ideas and information expressed herein are solely those of the author and do not necessarily reflect the positions, views or advice of Block.one or any other employee of Block.one.Originally published at block.one.Four Reasons Why Developers and Enterprises Are Looking at the EOSIO Blockchain Protocol was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 01. 21

EOSIO Version 1.6.0:

EOSIO Version 1.6.0: Significant Increase in Performance, New Tools in CDT, and a Thank You to Community ContributorsAs a contributor to the development and enhancement of the EOSIO software, we are pleased to confirm stable releases for EOSIO and EOSIO.CDT. You can find more detail about EOSIO V1.6.0 and EOSIO.CDT V1.5.0 in their respective GitHub repositories. Documentation, as always, is updated on the EOSIO Developer Portal.In order to make our contribution, we are actively engaged in how businesses are building applications on the EOSIO software and make proposals to improve the developer experience with EOSIO.Highlights in EOSIO V1.6.0Significant Performance ImprovementsIn line with the ongoing ambition to improve the performance of EOSIO, keeping it among the fastest protocols on the market, a large portion of this release has contributed to substantial performance increases for applications of the EOSIO software. Specifically, these updates should increase the efficiency of the peer-to-peer networking layer and real-time transaction throughput which would ultimately improve overall transaction speed.“Our own internal benchmark tests show upwards of a 35% increase in likely transaction speed when using token-transfers-per-second as our base case.”This benchmark represents testing the EOSIO software on a private network. We are projecting noticeable improvements to sustainable transactions per second, reduced CPU costs, and lower latency on all EOSIO based blockchains.NOTICE: State History Plugin (Fix Updated) (#6496)In EOSIO V1.5.0, an alpha version of the State History Plugin should allow real-time/streaming access to data from a blockchain. Akin to efforts with Demux, the State History Plugin is intended to allow for a more convenient way to get data through more web-scalable RPC frameworks. Overall this has become the basis for many scalability improvements in building on EOSIO. Throughout the alpha period we have been working to improve the plugin and engage with the rest of the community using it in their development workflow on EOSIO.Please see the issue in GitHub linked above for more specific technical details of the implementation and recent updates made. In summary, serialization for permission_object failed when both it and its parent were deleted. We anticipate this issue may affect any EOSIO-based blockchains, and applications may need to be restored from a snapshot made prior to an affected block to continue.Highlights in EOSIO.CDT V1.5.0Enhanced Tooling for Smart Contract DevelopmentIn EOSIO V1.3.0, we announced the EOSIO Contract Development Toolkit (EOSIO.CDT) — a toolkit which is intended to ensure more streamlined and efficient development on EOSIO when compiling smart contracts and generating ABI files. EOSIO.CDT is designed to provide added support for Gnu & C++ 11 style and should create a more reliant way of declaring your smart contract structure and associated data structures when building an application.New tooling has been created in the latest release, V1.5.0, aimed at enhancing the simplicity of creating, developing, and testing EOSIO smart contract development. A new tool, eosio-init, was introduced in (#317) that generates a template project for smart contract development. It creates a new binary within EOSIO that builds a basic structure for you to more easily get started with smart contract development.A full list of issues for EOSIO V1.6.0 and EOSIO.CDT V1.5.0 can be found in their respective GitHub repositories.Community Developer SupportIn addition to our growing team at Block.one we would like to send special thanks to a few community contributors who have submitted patches for this release. We’re grateful for your contributions and commitment to the growth of the EOSIO software.@conr2d@evsward@necokeine@iamveritas@UMU618Going ForwardRelease CandidatesA brief reminder that new versions of EOSIO and EOSIO.CDT will be marked as ‘Release Candidates’ (-rc) when ready for first compiled release to allow for more thorough testing and documentation. After a few cycles of feedback and once documentation is completed, the release will be promoted to ‘stable’. In the case of V1.6.0-rc1, which was tagged last month, we have named it V1.6.0 and merged into master on the GitHub repository.Benchmark Performance TestingThe automation team at Block.one is focused on helping to develop more consistent replicable benchmark tests that can be shared with the community to project performance increases of the software with each release. Our current benchmarks are projected as a percentage improvement above the latest prior stable version of the EOSIO protocol (V1.5.3). Stay tuned for more updates as we are able to share more about our benchmark and testing process to chart performance of the EOSIO software.Stay ConnectedIf you are interested in providing feedback and working more closely with our team to improve the EOSIO software for developers, you can send our developer relations team an email at developers@block.one.You can also stay up to date on future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be continually improving the usability of the software for EOSIO developers as we continue laying a foundation for the mass adoption of blockchain technology.DisclaimerBlock.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any applications related thereto. We make no representation, warranty, guarantee or undertaking in respect of the releases described herein and the related GitHub release or the EOSIO software, whether expressed or implied, and disclaim all liability that may arise from any use of the software for any purpose.EOSIO Version 1.6.0: was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

19. 01. 18

EOSJS Version 20-beta3: Rea...

Today we released the beta3 update to EOSJS v20.0.0. There are breaking changes in the release, so it is important for integrators to have their dependency versions locked. The changes in the release are a further step towards our plan to enable Dapp developers to integrate with one universal api and automatically support any key management and signing solution of their users’ choice.Feedback is welcome on our continued advancement of developer tools and resources for the EOSIO Developer Community. Feel free to get in contact with our Developer Relations team by emailing developers@block.one with your thoughts on how we can improve software development for the community.Continue reading below to learn more about EOSJS v20.0.0-beta3.Highlights in EOSJS v20.0.0-beta3:Remove dependency on eosjs-ecc (#425)In this release, we removed the “default” signature provider from the default export. Keeping this out of the default export prevents eosjs-ecc from being bundled automatically, significantly reducing bundle size. We made this change to heighten user security across applications by encouraging the use of signature providers instead of having users paste private keys directly into applications. In the future, we hope that most eosjs implementations will leverage an alternate signature provider to enhance user security.Support for React Native Apps (#425)We’ve made necessary updates to ensure eosjs is compatible with React Native Apps and the Edge/IE11 browser.Support for Signature Providers to Modify Transactions (#418)As we move to a more secure method of key handling within applications built on EOSIO, signature providers may have valid reasons to modify a transaction (i.e., add actions) prior to returning it to the API transact method for possible broadcast. Prior to this update this was not possible, as signature providers could only return signatures, and transact uses the same serialized transaction that was passed into the signature provider. With this update, the signature provider now returns an object with two keys: signatures and serializedTransaction. The transact function then broadcasts this output.Improved Handling of Multisig Transactions (#432)Finally, we have made some updates to provide better support for multisig transactions on EOSIO.Additional Issues:More details for this release can be found on GitHub in the Release. Remember, EOSJS V20 is still in beta and will be updated frequently to enhance the security and usability of the library. Remember to lock your dependencies.Stay ConnectedAs always, if you are interested in providing feedback and working more closely with our team to improve EOSIO for the community, you can send our developer relations team an email at developers@block.one. You can also hear about future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be continually improving the usability of the software for EOSIO developers as we continue laying a foundation for the mass adoption of blockchain technology.Read disclaimerEOSJS Version 20-beta3: React Native Support and Enhancements for Signature Providers was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

18. 12. 19

#BuiltonEOSIO: FITBLOX Puts...

#BuiltOnEOSIO: FITBLOX Puts Users in Control of Their Fitness — And Their DataCo-founder and CEO Peter M. Dray tells Block.one about his Wyoming, USA-based team’s vision of combining secure fitness-tracking technology and incentive-based social mediaHow would you describe your dApp?Peter M. Dray: FITBLOX is at the intersection of user-monetized social media and secure fitness-tracking technology. The FITBLOX dApp will enable users to control their own data and content by providing access to secure fitness-tracking technology merged with an immersive, incentive-based social media experience. Our dApp will leverage Delegated Proof of Stake (DPoS) as the basis for our stake-weighted voting system, which will enable content creators to be rewarded by the community for sharing useful content. FITBLOX will offer users access to a symbiotic marketplace for Health & Fitness products and content, creating a 360° user experience.https://medium.com/media/21db83f43dec612607c1efe01f61f764/hrefWhere did your initial idea come from?Peter M. Dray: In 2017, when work began on FITBLOX, it was our belief that incentive-based rewards models that “pay” users for creating and curating content were the future. We identified two major problems with existing social media apps: security and censorship. Simultaneously, we identified a huge opportunity in the Health & Fitness sector. With 200 million users globally, fitness apps represented one of the fastest growing categories. The 2018 Under Armour Myfitnesspal breach that exposed the personal data of 150 million users gave credence to our hypothesis that bad actors wanted to exploit this data. The synergy of these concepts led us to develop FITBLOX, which lets users track their fitness goals, share their journey with others, and be rewarded for demonstrating and encouraging inspired healthy behavior.Can you introduce your team and tell us what makes it special?Peter M. Dray: I’m Peter M. Dray, our CEO. Brian Hazan is our Chief Operating Officer, Brandon Parker is our Blockchain Strategist, and Peter L. Dray is a co-founder of the company. We’re early-adopting crypto veterans with a shared passion for wellness, health, fitness, and competitive athletics. Our wider, cross-functional team is comprised of Health & Wellness industry veterans, seasoned marketing experts, developers, traders, investors, and blockchain enthusiasts spanning a number of different industries. We believe our experience in launching Health & Wellness brands, paired with our blockchain expertise and expansive network of professional athletes, fitness celebrities and corporate sponsors, distinguishes our team.What stage is the project at and what are your plans for scaling up?Peter M. Dray: We’ve completed our technical stack and architecture framework and we’ve built out the development architecture and development environment for our planned roadmap. We’re currently in the initial development stages of our dApp design and we’re in the process of scaling up dApp development resources and adding DPoS EOS blockchain developers. At present, we plan on launching the Alpha in Q1 2019, Beta in Q2 of 2019 and our GA release of the FITBLOX dApp in the second half of 2019.Why did you decide to use blockchain technology, and specifically EOSIO?Peter M. Dray: We actually delayed our dApp development to coincide with the EOS mainnet launch. With dApp design in mind, EOS is the only blockchain protocol able to handle the high level of transactions that a fitness/social dApp will demand at scale. Additionally, DPoS and stake-weighted voting functionality are critical components for us. The Ethereum network was, quite frankly, too slow at 12 tps and too costly with gas fees, making it a non-starter. EOS provided the infrastructure and platform to bring FITBLOX to fruition.How has the EOS Community responded to your project?Peter M. Dray: We’re humbled by the overwhelmingly positive feedback and support from the EOS community thus far. This high level of community engagement and support was one of the biggest contributing factors leading to our decision to launch our project on the EOSIO blockchain. Many of our team members have been actively engaged in EOS networking events, meetups, and developer groups over the past year. This has helped us to gain valuable insights and overcome challenges with the aid of developers and block producers that have literally reached out to us to lend their services.Stay tuned to our EOSIO Spotlight series where we’ll highlight some of the truly exceptional projects being built on our platform. If you have a project you’d like to share with us, please email spotlight@block.one.-Developer Relations teamRead disclaimer#BuiltonEOSIO: FITBLOX Puts Users in Control of Their Fitness — And Their Data was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

18. 12. 12

#BuiltOnEOSIO: Azarus Takes...

Alex Casassovici tells Block.one about a platform that allows players to define and run their own challenges on their own termsHow would you describe your app?Alex Casassovici: Azarus is a game challenge network. The idea is to let every player define and run their own challenges on their own terms. We have been working with publishers to get access to the best possible sources of data, letting us know what happens in games in almost real-time. This data is then “oraclized” to feed smart contracts that operate the challenges.Rogue9 live streaming Ubisoft’s Rainbow 6 Siege on Twitch while running the Azarus extensionWhere did your initial idea come from?Alex Casassovici: When we started working on Azarus, the whole team aligned quite quickly around a thesis: “challenges” are the language of the gamer. Sixteen years ago, Xbox Live defined the first achievement network, later copied by Sony, Steam, Apple, and Android. Yet, that first step has aged as there is only so much that players will do for trophies. Games have been changing drastically from titles sold in retail boxes to long-lasting “live” games. In that context, retaining users is at least as important as acquiring new players. We realized that challenges wield an untapped power: to let players have even more fun with games they already love by putting some skin in the game. We also recognized that whatever we do must be done in partnership with publishers.Can you introduce your team and tell us what makes it special?Alex Casassovici: Our founding team, based in San Francisco, is comprised of seasoned gaming executives and entrepreneurs who believe blockchain will redefine relationships between game publishers and their customers. I’m Alex Casassovici and I’m a technologist and engineer who has built several companies around data telemetry and analysis. Andrew Lacy is a serial entrepreneur who has founded and led many successful startups, including Tapulous. Erik Whiteford is a seasoned game publishing executive who has led marketing efforts for brands including EA Sports, EA Games, 2K Sports, and Wargaming. Benjamin Devienne is a former academic researcher who has worked for EA, Ubisoft, Gameloft and Facebook.Azarus founders, from left to right: Benjamin Devienne, Erik Whiteford, Alex Casassovici, Andrew LacyWhat stage is the project at and what are your plans for scaling up?Alex Casassovici: We went live for a first alpha-test in late September in partnership with Ubisoft on their flagship title Rainbow Six: Siege. Ubisoft designed and funded challenges, rewarding viewers watching Twitch streams while paying great attention to what was happening in a match. At the end of each match, a challenge would be generated, firing off a question on the viewer’s screen through a Twitch Extension running on top of the stream. The question would focus on a specific statistic, and viewers with the right answer would split the AZA credit pool set by the streamer. AZA credits can then be exchanged on azarus.io for in-game items. That first test was a tremendous success, proving that the mechanics were capturing attention at unprecedented levels.Why did you decide to use blockchain technology, and specifically EOSIO?Alex Casassovici: Shady sites have plagued the gaming universe for years, from fake codes and black markets, to illegal tournaments and gambling/betting platforms. In response, we built a platform that runs in the open, that’s sanctioned by publishers and that stays away from betting and gambling. Blockchain’s core value is to create trust across a group of people that have little to no reason to trust each other. Our AZA credit is a virtual currency, akin to the ones of actual games. It’s a measure of the time players spend on the platform and of their skills / understanding of the game. In that context, transparency means the platform works as a self-regulating community, with hundreds of users digging in the logs and debating over the rightfulness of the outcome. With EOSIO, users can interact with the blockchain without having to know how it works. That and its transaction speeds made it the best choice for us.How has the EOS Community responded to your project?Alex Casassovici: Block producers and exchanges have been very enthusiastic about the project. We’ve been working with some community members to help define the proper architecture that will allow us to move to the mainnet, as well as financial options to give us enough CPU / Bandwidth / RAM staked to support it. That support has been extremely helpful.Stay tuned to our EOSIO Spotlight series where we’ll highlight some of the truly exceptional projects being built on our platform. If you have a project you’d like to share with us, please email spotlight@block.one.-Developer Relations teamRead disclaimer#BuiltOnEOSIO: Azarus Takes Gaming ‘Challenges’ to a New Level on Blockchain was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS

18. 12. 03

Transaction History
Transaction History Market Market Transaction volume Address
Bibox EOS/ETH 5,002.18 55,479,961,149.83 Short cut
ZBG EOS/USDT 4,985.37 50,867,310,102.63 Short cut
DragonEx EOS/USDT 4,982.39 34,717,229,340.28 Short cut
TOPBTC EOS/CNY 5,216.08 26,240,286,504.14 Short cut
Hotbit EOS/USDT 4,965.72 22,708,096,779.56 Short cut
RightBTC EOS/ETH 5,260.03 20,280,595,874.92 Short cut
DOBI Exchange EOS/USDT 4,989.00 19,382,219,731.56 Short cut
CoinEgg EOS/USDT 4,969.80 19,107,532,929.33 Short cut
BCEX EOS/CKUSD 7,482.77 17,614,170,888.94 Short cut
OEX EOS/USDT 4,981.08 15,786,181,493.32 Short cut
IDCM EOS/BTC 4,999.61 15,531,828,739.63 Short cut
BITHUMB EOS/KRW 5,065.00 10,486,459,630.23 Short cut
EXX EOS/ETH 4,998.58 10,191,618,170.50 Short cut
IDAX EOS/ETH 5,003.68 9,140,151,931.02 Short cut
BitForex EOS/ETH 5,003.66 8,233,203,403.76 Short cut
BITKER EOS/ETH 5,006.98 7,967,005,088.73 Short cut
DigiFinex EOS/ETH 5,003.86 6,876,343,097.71 Short cut
CoinMex EOS/BTC 5,002.37 6,237,183,553.30 Short cut
Bitrabbit EOS/ETH 5,010.33 6,098,967,324.64 Short cut
FCoin EOS/BTC 4,997.10 5,957,252,082.07 Short cut
Coinall EOS/BTC 5,004.70 5,676,132,116.20 Short cut
CoinBene EOS/BTC 4,992.34 5,631,933,134.97 Short cut
ZB.COM EOS/BTC 4,999.93 5,258,988,046.15 Short cut
Hubi EOS/BTC 5,009.96 4,340,974,010.11 Short cut
LBank EOS/ETH 4,904.79 3,905,153,631.47 Short cut
55 Global Markets EOS/ETH 5,007.49 3,896,025,869.99 Short cut
Cat.Ex EOS/ETH 5,016.35 3,617,532,733.92 Short cut
Kryptono EOS/ETH 3,825.18 2,666,030,755.80 Short cut
Dcoin EOS/ETH 5,007.55 2,446,505,770.43 Short cut
Coineal EOS/ETH 5,008.01 1,334,238,864.41 Short cut
OKEx EOS/OKB 4,951.68 1,144,418,678.24 Short cut
Fatbtc EOS/USDC 4,825.64 1,049,860,972.71 Short cut
YunEx EOS/USDT 4,984.43 612,547,998.04 Short cut
TOKOK EOS/ETH 4,997.88 490,973,867.13 Short cut
CoinEx EOS/ETH 4,999.91 464,146,836.77 Short cut
CHAOEX EOS/ETH 4,997.03 415,758,612.43 Short cut
Huobi Global EOS/HT 4,990.26 408,841,474.30 Short cut
MERCATOX EOS/ETH 4,842.72 315,982,084.01 Short cut
Bit-Z EOS/BZ 4,940.51 298,889,293.58 Short cut
UPbit EOS/BTC 4,975.06 193,360,279.89 Short cut
BBX EOS/USDT 4,976.09 160,377,423.57 Short cut
BW.com EOS/ETH 5,004.13 153,420,834.76 Short cut
Instant Bitex EOS/BTC 5,010.39 144,520,197.66 Short cut
Binance EOS/TUSD 5,006.01 130,309,826.85 Short cut
Bitfinex EOS/GBP 4,966.63 115,434,705.58 Short cut
Paribu EOS/TRY 5,007.93 54,869,792.74 Short cut
Gate.io EOS/BTC 4,973.41 42,127,676.58 Short cut
BigONE EOS/ETH 4,998.06 33,652,938.04 Short cut
Bitrue EOS/ETH 5,010.06 31,607,457.92 Short cut
Kucoin EOS/KCS 4,995.66 28,414,527.70 Short cut
Coindeal EOS/BTC 4,999.67 23,140,458.67 Short cut
Bancor Network EOS/BNT 4,939.69 21,814,259.89 Short cut
EXMO EOS/EUR 5,563.31 19,234,489.16 Short cut
BX Thailand EOS/THB 5,002.51 18,795,054.89 Short cut
Kraken EOS/ETH 4,980.48 16,176,813.03 Short cut
BHEX EOS/BTC 4,993.40 15,867,524.65 Short cut
Bitbns EOS/INR 5,708.40 7,702,741.57 Short cut
Trade.io EOS/USDT 4,984.12 4,333,937.59 Short cut
Huobi Korea EOS/HT 4,981.98 3,763,192.94 Short cut
Koineks EOS/TRY 4,845.77 3,238,880.32 Short cut
BitMax EOS/ETH 4,911.39 2,325,561.87 Short cut
HitBTC EOS/PAX 4,961.70 1,343,953.28 Short cut
YObit EOS/ETH 4,016.61 504,293.83 Short cut
LiveCoin EOS/USD 4,732.60 24,988.14 Short cut
GOPAX EOS/ETH 6,500.47 13,000.94 Short cut
Koinex EOS/INR 2,559.13 12,795.66 Short cut
BitMart EOS/BMX 7,584.08 12,286.32 Short cut
Exrates EOS/USD 10,181.10 10,982.15 Short cut
CPDAX EOS/BTC 4,975.06 9,950.11 Short cut
RuDEX EOS/BITUSD 5,057.72 0.00 Short cut
GBX Digital Asset Exchange EOS/USD 5,949.18 0.00 Short cut
COSS EOS/TUSD 8,718.31 0.00 Short cut
CryptoMarket EOS/BRL 5,022.64 0.00 Short cut
ABCC EOS/USDT 3,403.39 0.00 Short cut
CoinZest EOS/ETH 71,044.72 0.00 Short cut
Coinbe EOS/BTC 8,868.74 0.00 Short cut
OTCBTC EOS/USDT 5,050.45 0.00 Short cut
Tidebit EOS/HKD 3,765.54 0.00 Short cut
Chaince EOS/ETH 4,782.64 0.00 Short cut
Coinsuper EOS/CEN 4,478.98 0.00 Short cut
Bitinka EOS/BTC 5,062.85 0.00 Short cut
WazirX EOS/INR 6,005.43 0.00 Short cut
OpenLedger DEX EOS/XSD 3,422.66 0.00 Short cut
CredoEx EOS/CREDO 7,522.53 0.00 Short cut
Cryptomate EOS/GBP 5,402.53 0.00 Short cut
CoinTiger EOS/TRX 4,809.78 0.00 Short cut
Bilaxy EOS/ETH 5,937.31 0.00 Short cut
BCoin.sg EOS/BTC 3,602.46 0.00 Short cut
Escodex EOS/BTC 9,138.76 0.00 Short cut
Allcoin EOS/USDT 4,697.95 0.00 Short cut
Iquant To be provided later To be provided later To be provided later Short cut
Lykke To be provided later To be provided later To be provided later Short cut
Coinbase Pro To be provided later To be provided later To be provided later Short cut
Zebpay To be provided later To be provided later To be provided later Short cut
Abucoins To be provided later To be provided later To be provided later Short cut
ProBit Exchange To be provided later To be provided later To be provided later Short cut
Cashierest To be provided later To be provided later To be provided later Short cut
CoinFalcon To be provided later To be provided later To be provided later Short cut
DDEX To be provided later To be provided later To be provided later Short cut
Cryptopia To be provided later To be provided later To be provided later Short cut
xBTCe To be provided later To be provided later To be provided later Short cut
Tidex To be provided later To be provided later To be provided later Short cut
Independent Reserve To be provided later To be provided later To be provided later Short cut
YUNBI To be provided later To be provided later To be provided later Short cut
POLONIEX To be provided later To be provided later To be provided later Short cut
CoinExchange To be provided later To be provided later To be provided later Short cut
coinone To be provided later To be provided later To be provided later Short cut
Hadax To be provided later To be provided later To be provided later Short cut
BtcTrade.im To be provided later To be provided later To be provided later Short cut
CHBTC To be provided later To be provided later To be provided later Short cut
Bter To be provided later To be provided later To be provided later Short cut
Kuna To be provided later To be provided later To be provided later Short cut
C2CX To be provided later To be provided later To be provided later Short cut
COBINHOOD To be provided later To be provided later To be provided later Short cut
BitMEX To be provided later To be provided later To be provided later Short cut
Liqui To be provided later To be provided later To be provided later Short cut
ZB To be provided later To be provided later To be provided later Short cut
ACX To be provided later To be provided later To be provided later Short cut
DSX To be provided later To be provided later To be provided later Short cut
Ovis To be provided later To be provided later To be provided later Short cut
SIMEX To be provided later To be provided later To be provided later Short cut
Bleutrade To be provided later To be provided later To be provided later Short cut
Braziliex To be provided later To be provided later To be provided later Short cut
Security verification

There is security verification of the project
Why security verification is necessary?

Read more

comment

* Written questions can not be edited.

* The questions will be answered directly by the token team.

  • hb**** Jun 08. 2019

    이오스 타거래소에서 옮겨오려고하는데 입금지갑주소를 찾을수없네요~~알려주세요

  • hb**** Jun 08. 2019

    이오스 타거래소에서 옮겨오려고하는데 입금지갑주소를 찾을수없네요~~알려주세요

  • angelreu80 Dec 07. 2018

    더이상 에어드랍은 안해주나요?

  • 뻑치기우루사 Nov 20. 2018

    뉴덱과 빅원에 거럐중인 코인이 많은데 지갑전송 열어주세요!

  • 고봉도사 Nov 09. 2018

    Trybe에어드랍 안해주나요
    체인스에 상장하던데요

  • ym49 Oct 16. 2018

    안녕하세요. KEOS 팀에서 이메일이 왔습니다. 'KEOS 홀더를 위하여 추가 마이그레이션을 진행합니다. 반드시 이번 기간 내 마이그레이션을 진행해주세요!'(이하 생략) 토큰뱅크 에어드랍된 KEOS는 어떻게 되는건지, 별도 절차없이 마이그레이션되는건지 궁금하여 문의드립니다!

  • Boluck Oct 04. 2018

    및에이어 2번째 페이지 입니다.

    것과같은 문의방식이 몇번 있다가 불행 하게도...9월 19일 해당계좌에서 거래소로 저의 eos가 출금되었습니다.

    사고발생후 급박한 2주동안 아무런 조치도 취해 주지 않았고 무책임 앞에서 당당 하셨습니다.

    토큰뱅크가 출금을 잘못한게 아니고 본인이 틀리게 출금을 한거죠! 거의 마지막 답변으로 기억합니다.
    기가 막히고 황당해서 아직도 몸이 부르르 떨립니다.

    아래 ECAF 에 컨텍 넣으셨다는데 컨텍넘버가 어떻게 되는지요? 몇번이나 컨텍을 넣으셨는지,출금 거래소에 동결 요청 하셨다는데 결과 공문이 어떻게 왔는지 ? 궁금한 것이 참 많습니다.

  • Boluck Oct 04. 2018


    9월13일 문의 게시판 답변이 10월이 지나서야 주셨네요.

    저는 외국에 체류하고 사고시점이 9월5일 입니다.
    사고 발생후 지속적으로 메일과,국제전화로 실수로 오입금이 발생 했으니 ,수습과 중재 방안을 요청 드렸어요.

    귀사는 마치 녹음기 처럼 본인의 실수로 오입금되어 방법이 없다는 말만 사람이 바뀌며 계속 말씀 하셨고 2~3일 후엔 답변 조차 주지 않았죠.

    9월9일 저는 귀사에 ECAF 라는 이오스 중재기관을 통해 해당계좌에 대한 우선동결을 요청해 달라 부탁 드렸습니다.
    또 응답없이 몇일이 지났고 게시판,고객문의,귀사의 이전 법인의 E-Mail로도 보냈습니다.

    물론 개인적으론 이미 ECAF,Eos911,등 컨택을 하였지요.
    ECAF의 영향력 있다는 관계자분들 과의 접촉도 시도 하였지만 개인의 역량으론 역부족 이었습니다.

    9월 14일 되어서야 고객관리 팀장님과 통화후 최대한 도와 주신다는 답변을 들을수 있었으나 이후로도 진행상황과 답변은 들을수 없었고 ,마치 제가 재촉하는

  • 201820 Oct 03. 2018

    이오스 에어드랍 안뜨네요 ㅠ

  • wi**** Sep 19. 2018

    공지는 잘올려도 요즘 문의게시판은 관리를 안하네요 공지올리면서 한번은 볼듯한데...처음과는 다르게 믿음을 못주시네요

    EOS Person in charge Sep 19. 2018

    안녕하세요. 답변이 늦은 점 죄송합니다. 최대한 꼼꼼하게 답변 드리겠습니다.
    부족한 부분 보완해나가겠습니다.

  • Boluck Sep 13. 2018

    지난 9일 저는 최소한의 권리에 대해 귀사에 요청 드렸습니다.  
    ECAF(이오스중재기관)(https://eoscorearbitration.io) 에 submit claim,중재를 요청하는 제안서라도 먼져 보내 상황 보고라도 해주시길 메일로 긴급히 요청 드렸습니다. 허나 이후 지금까지 몇분도 걸리지 않는 양식 작성 제안의 이행도,저에게로의 어떤 종류의 피드백도 없었고 무시로 ,무대응 하며 오히려 철저히 고객의 최소한의 권리행사 마져 막아 버리는 귀사의 행태에 경악을 넘어 분노하게 됩니다.

    힘없는 일개 개인인 저는 나름대로 최선을 다해 저의 권리를 찾으려 합니다.언론을 통해 귀사의 횡포에 가까운 부당함을 알리고,사이버수사대에 신고 처리하는 고단한 과정과,소비자보호원 제안,국민청원등 모든 방법을 동원해 앞으로 발생할 피해자를 막고 저의 권익을 찿을것입니다.

    EOS Person in charge Sep 13. 2018

    안녕하세요. 토큰뱅크입니다.
    부족하나마 ECAF 기관 컨택 및 문의, 출금 거래소 측에 계좌 동결 요청 등을 요구하였습니다.

    다만 본 요청이 실제 소유하고 있는 본인이 아닐 경우,
    해킹의 소지로 문제가 발생한 경우가 아닐 경우 실행이 어려운 점 양해 부탁드립니다.

  • Boluck Sep 07. 2018

    안녕하세요. 저는 지난9월5일 토큰뱅크 에서 훠비로 EOS를 오출금 하였습니다 . 계좌명을 huobideposit 를houbideposit 로 잘못 적었지요. 분명 저의 잘못입니다. 다분히 악의적인 훠비계좌로 잘못 보내진 것입니다. 상담원분과의 상담과 사유서도 요구 양식에 따라 E-mail 로 제출 하였습니다. 스스로 찿아 상대계좌가 EOS dap관련된 써브계좌 세컨드 계좌임도 보충메일 보내 드렸습니다.

    이메일로 온 답변은 이미 다른계좌로 잘못이체된 상태라 방법이 없다는 ...제가 받아들이기에는 아무 조치도 ,어떤 노력도 하지 않았다는 무성의한 답변에 허탈감이 이루 말할수없었습니다.

    저의 개인 계좌가 아닌 보낸계좌(갑)이 토큰뱅크이고 잘못보낸계좌가(을) 이기에 더구나 그계좌에는 제가 보낸 Eos 수량밖에 존재치 않기에 EOS bp후보인 토큰뱅크가 문제제기후 동결 ,조정의 절차를 밟아 처리될것이라고 믿고 있었기 때문입니다.

    EOS Person in charge Sep 07. 2018

    무엇보다 관련된 오입금이 더이상 발생하지 않도록 노력하겠습니다.

  • wi**** Sep 07. 2018

    수고하십니다!~에어드랍도 잘해주시고 감사하게 생각합니다 근데 게시판 답변은 빨리해주셨으면 좋겠습니다 혹시나 답변이 달렸을까? 3~4일 연속으로 토큰뱅크 드나드는것도 그렇구요~이틀전 비트코인 하락으로 이오스빼고싶었는데 문의 답변이 늦어 빼지를 못했네요~답변이라도 빨랐다면 벌써 빼고 다시 이오스 저점잡아했을텐데...뭔가 아쉽습니다

    EOS Person in charge Sep 07. 2018

    알겠습니다. 답변을 실시간으로 드릴 수 있도록 노력하겠습니다.

  • Boluck Sep 05. 2018

    주소를 huobideposit 를 houbideposit로 오입금 하였습니다 전화 상담 요구 합니다.

    EOS Person in charge Sep 05. 2018

    안녕하세요. 답변이 늦어진 점 죄송합니다.
    관련하여 전화 상담을 진행하였습니다.

  • wi**** Sep 04. 2018

    이오스 최근 15일 전까지 평소하던데로 업비트 -> 토큰뱅크 , 토큰뱅크 -> 업비트 주소복사,메모복사 해서 이오스 이동 잘했는데 이제는 무조건 메모복사뒤 - 일일이 붙여야 하나요?

    주소,메모 복사로만 이오스 그대로 왔다면 평소대로 옮겨도 되는지 궁금합니다

    EOS Person in charge Sep 04. 2018

    메모 복사 후 붙여넣기 시 - 는 삭제해주셔야 합니다!

  • 한방이오스 Sep 02. 2018

    스캐터 ridl 스냅샷 끝났나요?
    공지가 없네요

    EOS Person in charge Sep 02. 2018

    스냅샷은 정상적으로 완료되었습니다.

  • ym49 Aug 29. 2018

    이오스 입금확인 했습니다.
    제네시스 스냅샷, 에어드랍 토큰들
    체인스 거래소 입출금 버튼 있는 에어드랍 건에 대해서는 토큰뱅크도 입, 출금 버튼을
    빠른 시일내에 만들어주시면 감사하겠습니다.(BOID. ATD. BLACK.
    MEETONE. CHL. EDNA. ADD. OCT 이상
    체인스 입, 출금 가능 이오스 에어드랍 토큰)
    수고하세요!~

    EOS Person in charge Aug 29. 2018

    네 감사합니다. 배분받으신 에어드랍 토큰의 입출금이 원활할 수 있도록 노력하겠습니다.

  • wi**** Aug 29. 2018

    이오스 제네시스 스냅샵이 9월1일 인가요?

    EOS Person in charge Aug 29. 2018

    하반기 에어드랍의 스냅샷 일정이 9월 1일, 7일등 다양하게 존재합니다.

    제네시스 스냅샷은 이오스가 처음 메인넷으로 구동되는 시점의 스냅샷을 뜻합니다.

  • 우리가족화이팅 Aug 25. 2018

    에브리디피아 업비트로 주소는 입력햇는데 메모를 입력을 이상하게해서 토큰이 다없어졋어요 도와주세요

    EOS Person in charge Aug 25. 2018

    네 문제가 발생할 경우, cs@tokenbank.co,kr 로 문의주세요.
    도움 드릴 수 있는 부분에서 최대한 도움 드리겠습니다.

  • wi**** Aug 16. 2018

    이오스 하반기 에어드랍일정은 어떻게 되나요?

    EOS Person in charge Aug 16. 2018

    추가되는 에어드랍들은 정기적으로 업데이트 중입니다. 공지사항을 확인해주시면 감사하겠습니다.

Information
Platform EOS
Accepting
Hard cap -
Audit -
Stage -
Location -
Market of major crypto coins *2019년 07월 22일 last update

Bitcoin

BTC

12,273,889.65 KRW 4.50%

Ethereum

ETH

259,350.59 KRW 5.06%

Ripple

XRP

383.64 KRW 2.94%

Litecoin

LTC

114,933.78 KRW 5.32%

Bitcoin Cash

BCH

370,879.23 KRW 5.51%

Binance Coin

BNB

35,314.96 KRW 3.22%

Tether

USDT

1,176.54 KRW 0.55%

EOS

EOS

4,978.90 KRW 4.14%

Bitcoin SV

BSV

194,773.73 KRW 5.64%

TRON

TRX

32.65 KRW 7.70%

Stellar

XLM

105.67 KRW 6.53%

Cardano

ADA

70.75 KRW 7.41%

Monero

XMR

98,300.86 KRW 3.47%

Dash

DASH

137,847.93 KRW 2.63%

NEO

NEO

14,904.80 KRW 7.27%

Ethereum Classic

ETC

7,242.04 KRW 2.04%

Tezos

XTZ

1,225.70 KRW 0.68%

NEM

XEM

78.21 KRW 5.13%

Maker

MKR

663,256.87 KRW 1.58%

Ontology

ONT

1,189.58 KRW 5.21%