EOS REX

EOS 네트워크 임대 시스템

home link https://eosrex.io/

reference material

Community

Accumulated application
2,127,201 EOS
신청수량
Remaining time 1 day, 9 hours
Project introduction

EOS REX 청약 신청 주의사항

◼︎락업 기간 
: 청약 신청 시점 - 상환 시점까지

◼︎REX 교환 비율
: EOS 내부 시스템 상, EOS를 EOS REX로 변환하는 시점에 교환 비율을 알 수 있기 때문에 변환 후 공지사항을 통해 안내해 드리겠습니다.

1. EOS REX는 해당 회차의 청약 신청 기간 종료 후 이오스 렉스 지갑에서 확인 가능합니다.
2. 락업 기간 내에는 청약 신청한 EOS 출금이 불가합니다.
3. 락업 기간 내에는 청약 신청 취소가 불가합니다.
4. EOS REX 신청 가능한 최소 수량은 EOS 10개입니다.
5. 수익을 포함한 EOS 수량은 소수점 4번째 자리까지 지원합니다.
6. EOS REX를 신청하는 분들은 EOS 에어드랍과 같은 에어드랍 지원이 불가합니다.
7. EOS REX에 관하여 충분한 이해와 내용을 숙지하신 후 신청해주시기 바랍니다.



EOS REX는 Resource Exchange의 줄임말로 EOS 메인네트워크를 이용하기 위해 필요한 자원들을 토큰 홀더들이 필요에 따라 자유롭게 빌려주고 교환받을 수 있게 하는 교환 시스템을 의미합니다.

EOS 홀더들은 자신의 계정에 보유하고 있는 여분의 EOS 토큰이나 EOS 메인넷 상의 여유 리소스 (CPU/NET) 중 일부를 대여해주고 이에 대한 수익을 얻을 수 있습니다.

DApp 프로젝트와 개발자들은 개발에 필요한 리소스 (CPU/NET)를 일정 기간동안 대여받으며 이에 대한 수수료를 이자처럼 소액으로만 지불할 수 있습니다.

Executives and partners

Alex Gomory

EOSIO Stack Engineer

CESAR DIAZ

Lab Director

Ashish Chandra

Back End & Smart Contacts

EOS

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 REX

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 REX

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 REX

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 REX

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 REX

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 REX

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 REX

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 REX

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 REX

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 led 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 REX

19. 04. 12

#BuiltOnEOSIO: FireWall.X M...

To most people, the word ‘firewall’ is an unwelcome term, implying censorship, lack of access, and the curtailment of online freedom. For EOSIO developers, however, FireWall.X is more likely to be a helpful tool rather than a cyber obstacle, because the platform sets out to protect smart contracts built on EOSIO from malicious hacks and cyber threats, in turn contributing to the health of the overall EOS ecosystem. We spoke to Zhong Qifu, Product Manager at SlowMist Technology Co. (the company behind FireWall.X), about how “the world’s first firewall for smart contracts” intends to be the security guardian of all EOS applications.How would you describe your project?Zhong Qifu: FireWall.X is a powerful and practical firewall for smart contracts — it is also the world’s first firewall for smart contracts. Similar to traditional firewalls for operating systems which control network traffic, FireWall.X can also execute control over inline actions and prevent unauthorized access to smart contracts. Used in combination with oracle technology, there is the added benefit of risk management, which will help prevent hackers from obtaining any account information contained in smart contracts. For developers, FireWall.X makes their development process a lot easier, since all they need to do is to directly import our smart contract security enforcement document into their own code, after which they will be able to create a smart contract that is more resistant against cyber attacks — all at zero cost.Where did your initial idea come from?Zhong Qifu: In the latter half of 2018, we conducted some research into the many different ways one could carry out smart contract hacks, and discovered some of the major pain points and challenges surrounding the safety precautions of smart contracts. Following one of our many brainstorming sessions, a cybersecurity researcher on our team proposed the idea of FireWall.X, which naturally led us to the creation of this project. Our team’s expertise also lies mainly in cybersecurity technology, which is why we chose to focus on this aspect in the first place.Can you introduce your team and tell us what makes it special?Zhong Qifu: Our team possesses deep expertise and experience in cybersecurity-related matters. Many of our members have worked at eminent tech corporations such as Google, Microsoft, W3C, Tencent, Alibaba, Baidu etc., and some of their project achievements have been featured at the Black Hat Briefings — one of the most well-attended information security conferences in the world. So far, we have provided many EOS-based decentralized exchanges, wallets, and smart contract developers with security audits. Our clients include WhaleEx, Newdex, Chaince, MORE.TOP Wallet, MEET.ONE etc. When the public network launched in June 2018, our team compiled a guide titled “EOS BP Nodes Security Checklist”, aimed at providing community members with smart contract security support. In the following September, we utilized our experience in carrying out smart contract security audits to create a ‘Best Practice’ guide on ensuring the secure implementation of EOS smart contracts.What stage is the project at and what are your plans for scaling up?Zhong Qifu: At present, some of the fully functioning features of FireWall.X include malicious account screening, blacklist and whitelist management, statistical analysis, activity logging, as well as malicious transfer detection. These are all provided on a user-friendly platform for developers. Down the line, we will be launching a real-time statistical panel, as well as introducing risk management features in combination with an off-chain analysis tool. In a nutshell, these features and tools would enable apps to block off attacks in a timely manner, thus reducing the financial loss of users.Why did you decide to use blockchain technology, and specifically EOSIO?Zhong Qifu: Blockchain technology is superior in that it offers the benefits of immutability and accountability, which ensure that no data can be tampered with in the process. Blockchain can also improve identity verification and data authorization, which helps massively with elevating the efficiency of threat intelligence sharing. This is especially pertinent to our project, as it is centered on preventing cyber attacks. As for choosing to build on EOSIO, that’s because it is fast and easy to use. Since the launch of the public network, we have continuously seen a growing number of apps developing on the EOSIO protocol — this gives us high hopes for the EOSIO ecosystem.It has only been three months since FireWall.X has gone live, but we have already seen lots of positive responses to our project among members of the EOS community. So far, we have managed to get 23 projects on board with implementing FireWall.X. As of now, we have successfully blocked off a large volume of smart contract hacks, in the process protecting many apps from cyber attacks.More information on FireWall.X available on https://FireWallx.io/index-en.htmlStay 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.

EOS REX

19. 04. 11

EOSJS Stable Version 20.0.0...

Today, we are excited to announce the promotion of EOSJS v20.0.0 out of beta to a stable release. The changes in the release mark a further step towards more secure and user-friendly JavaScript development for applications built on EOSIO. To create a seamless secure user experience, we believe blockchain applications should almost never need to access a user’s private keys. We have been updating EOSJS to support applications that propose transactions to secure signature providers, such as authenticators that are able to focus their efforts on storing keys in the most secure way possible, as well as to provide a consistent user experience when signing transactions. More on our work with authenticators can be seen in our recent EOSIO Labs™ release: The Universal Authenticator Library.Since this release promotes breaking changes from EOSJS v20.0.0-beta3 to v20.0.0 (stable), using the @latest tag or the “^” will now automatically cause an upgrade from v16.0.x to v20.0.0. Developers who are still using EOSJS v16.0.x are recommended to also review the updated README, as this release is a complete rewrite which started from our initial EOSJS Major Version Update last October.A full list of issues for EOSJS v20.0.0 can be found in the GitHub repository.Highlights in EOSJS v20.0.0BREAKING CHANGE: Removal of default exports (#490)Using default exports causes inconsistencies depending on the module system used and makes refactoring code harder; therefore, they have been removed entirely from the EOSJS code. Developers using the JsSignatureProvider on v20.0.0-beta3 will need to update their syntax as follows: import JsSignatureProvider from ‘eosjs/dist/eosjs-jssig’ to import { JsSignatureProvider } from ‘eosjs/dist/eosjs-jssig’Reduced bundle size significantly (#504)Loading node modules from third parties is often the largest operation in a page load for end users. In order to minimize the loading time required for consumers of EOSJS, we have adjusted our distribution bundling process to exclude some unnecessary files. The EOSJS bundle size had been optimized since the v16.0.x release from 550kb to 130kb in v20.0.0-beta3. This change further reduces the bundle size from 130kb to 50kb.Export Numeric module functions (#511)The functions from the Numeric module can be useful for consuming applications. As such, we have decided to export them as part of our bundle for NPM and for the web build.Security UpdatesUpdate and lock dependency versions in package.json (#504)By using the “^” in package.json, the consuming package has control over when EOSJS dependencies update, which could lead to bugs upon updating automatically. To prevent this, we have locked all versions to a specific version, so we can have discretion over when dependencies update. We also updated some dependency versions to mitigate certain security vulnerabilities.Update and lock versions in EOSJS-ECC dependency (#49)EOSJS-ECC dependencies have been locked in order to mitigate low priority security vulnerabilities.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:@Mc01@channprj@jnordberg@wuyahuangStay ConnectedIf you are interested in providing feedback and working more closely with our team to improve the EOSJS repository 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.

EOS REX

19. 04. 04

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 REX

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 REX

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 REX

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 REX

19. 03. 29

Analysis report

EOS REX

EOS REX

[중요] 이오스 렉스 참여방법 (EOS 입금부터 ...

By 에밀리 | May 13. 2019 | 1551 read

안녕하세요!토큰뱅크 운영팀에 있는 에밀리입니다. 오늘부터 토큰뱅크에서 진행된 '이오스 렉스 (EOS REX)' 모르시는 분 계신가요? 혹시 이오스 렉스 신청하는 방법을 아직 모르시겠다고요?이제부터 제가 토큰뱅크에서 이오스 렉스 신청하는 방법에 대해  자세히 알려드릴게요 : )[이오스 렉스(EOS REX) 참여 방법] 1. EOS를 토큰뱅크에 입금하기  이오스는 주소와 메모 두가지 모두를 입력하셔야 합니다!주소는 토큰뱅크의 모든 고객님들이 동일하더라도 메모는 다르니 꼭 여.러.번 확인해서 적어주세요!  (*메모를 통해 고객님들을 구별합니다.)2. 이오스 입금 확인하기 이오스가 입금되면 제가 '이오스 수량 표기되는 부분'에 수량이 적힙니다.3. 이오스 렉스 신청하기이오스가 입금되었으면 이제 무엇을 해야할까요?우리는 이오스 렉스를 신청하기 위해 이오스를 넣었으니 이오스 렉스를 신청해야죠!현재 이오스 렉스는 '청약 신청하기'를 통해서만 신청이 가능합니다.( 토큰뱅크에서는 계속해서 이오스 렉스를 청약하는 방법 / 청약 후 보관하는 것에 대해   토큰뱅크 회원님들이 더욱 편하게 이용하실 수 있도록 업그레이드할  예정입니다. 조그만 더 기다려주세요! )청약 신청은 매일 열려있지 않아요! 신청할 수 있는 기간이 따로 있습니다.3-1. 청약 신청 날짜 확인하기  (feat. 공지사항) 청약 신청할 수 있는 날짜부터 시작해서 공지사항의 모든 것들을 꼭 꼼꼼하게 읽어주세요! 모든 내용이 너무 중요합니다. 3-2. 메인 홈페이지에서 '이오스 렉스 신청하기' 버튼을 클릭합니다. 신청할 수 있는 날짜라면 메인 홈페이지에서 '이오스 렉스 신청하기' 버튼을 눌러주세요.3-3. 내가 신청하고 싶은 EOS 수량을 정수로 기입합니다. 자 이제 이오스 렉스 청약 신청은 모두 끝났습니다! 다음은 이오스 렉스 입금 확인하는 방법부터 상환일에 내가 맡겨둔 이오스 + 수익금을 확인하는 방법 알려드릴게요.4. 신청 후 내가 받을 EOS REX는 청약 기간 종료일 이후 '이오스 렉스' 지갑에서 확인하실 수 있습니다. 5. 상환일, 청약 신청할 때 맡겨두었던 이오스와 수익금 확인하기 상환일에 내가 맡겨두었던 이오스와 수익금 확인은 회원님의 토큰뱅크 '이오스' 지갑에서 가능합니다. 자, 이렇게해서 이오스 렉스 신청부터 수익금 확인하는 방법까지 안내드렸습니다.궁금하신 사항은 댓글 남겨주시면 빠르게 답변드릴게요!감사합니다. 

0 0

Transaction History

Preparing to be listed on cryptocurrency exchanges
Please leave a message of support for the team

go to leave a message

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.

  • 준스임 Jul 11. 2019

    이오스 받으면 렉스없어지던데 그럼 렉스는 사용불가인가요?

    EOS REX Person in charge Jul 11. 2019

    안녕하세요. 렉스는 이해하기 쉽게 예를 들자면 고객님께서 REX를 신청했다는 영수증과 같은 역할을 합니다. 따라서 다른 용도로 사용되진 않습니다.

  • 에첼스 Jun 27. 2019

    3 ㅡ5차 렉스 이벤트 결과는 언제 나오나요?
    나왔으면 누가당첨됐는지 결과라도 알려주세요

    EOS REX Person in charge Jun 27. 2019

    안녕하세요. 다음주 중으로 이벤트 결과 및 지급될 예정입니다. 조금 늦어진 점 양해 부탁드리겠습니다. 감사합니다.

  • 용달이 Jun 19. 2019

    6차청약 종료 후 언제 다시 이오스로 받나요?

    EOS REX Person in charge Jun 19. 2019

    안녕하세요. 현재 5차 청약 신청을 받고 있으며, 5차 청약 종료, 이오스로 상환 받는 시점은 6월 26일(수) 입니다.

  • dr**** Jun 18. 2019

    이번 수익 상환액 너무 적은대요? 만개에 0.6개라니... 이 수준이라면 누가 사용할지...?

    EOS REX Person in charge Jun 18. 2019

    안녕하세요. 수익 상환액의 경우 렉스 시스템 상에서 정해지는 것이고, 밑의 댓글과 같이 수수료와 수익에 따라 변동될 수 있습니다.
    현재 토큰뱅크에서 3~5차 REX 청약 이벤트도 진행하고 있으니 한번 참고해주시면 감사하겠습니다.

  • DNSBY8K Jun 17. 2019

    왜 점점 더 상환액이 적어질까요..

    EOS REX Person in charge Jun 17. 2019

    안녕하세요. 이오스 렉스의 수익은 1) REX를 통한 자원 임대 수수료, 2) RAM 시장의 수수료, 3) EOS Name Auction 수익 등으로 구성되어 있습니다. 따라서 수수료와 수익 등이 얼마나 발생하는가에 따라 수익이 변동될 수 있습니다.

  • 에첼스 Jun 17. 2019

    4차 렉스 상환 몇시쯤 되나요?
    아직 안되었네요

    EOS REX Person in charge Jun 17. 2019

    안녕하세요. 오늘 오후 6시 이전에 상환될 예정입니다. 감사합니다.

  • juicek Jun 13. 2019

    청약할때 마다 렉스 지급 아닌가요?
    입금되었다가 출금되었다가?
    3번 청약했는데 지갑에는 1번 지급인데 요?

    EOS REX Person in charge Jun 13. 2019

    안녕하세요. 청약 신청 후 구매 시점에 렉스가 지급되고, 상환 시점에 렉스가 출금되며 이오스와 수익이 지급됩니다.
    저희가 확인했을 때에 고객님 지갑으로 네 번 렉스가 입금되었고 세번 렉스가 출금된 것으로 확인됩니다.

    추가적으로 문의하실 내용이 있으시다면 홈페이지 내 1:1 문의로 문의주시면 더 자세하게 답변드리도록 하겠습니다.

  • dr**** Jun 11. 2019

    4차신청 렉스 이오스로 언제 돌려받죠?

    EOS REX Person in charge Jun 11. 2019

    4차 청약의 상환 시점은 6월 17일 입니다. 다음주 17일(월)에 이오스로 지급될 예정입니다.

  • Saitama Jun 11. 2019

    지금은 렉스 신청할수없나요?

    EOS REX Person in charge Jun 11. 2019

    안녕하세요. 내일부터 5차 REX 청약 신청이 진행됩니다

  • 제지훈 Jun 11. 2019

    11일인데 렉스가 안들어오네요

    EOS REX Person in charge Jun 11. 2019

    현재 4차 청약 REX 지급이 완료되었습니다.

  • 킬패세숙 Jun 10. 2019

    4차렉스가안들어왓네요
    10일까지면 내일상환되나요?

    EOS REX Person in charge Jun 10. 2019

    현재 4차 청약 REX 지급이 완료되었습니다.

  • 킬패세숙 Jun 07. 2019

    저번주보다 이자가낮은데 이유가몬가요?

    EOS REX Person in charge Jun 07. 2019

    이오스 렉스의 수익은 REX를 통한 자원 임대 수수료, RAM 시장의 수수료, EOS Name Auction 수익 등으로 구성되어 있어 항상 일정하지 않고 변동하게 됩니다.

  • lswkelkel Jun 06. 2019

    3차 신청 상환기간이 언제까지인거죠?

    EOS REX Person in charge Jun 06. 2019

    안녕하세요. 답변이 늦은 점 죄송합니다. 3차 청약의 경우, 7일(금)에 상환되었습니다.

  • 제지훈 Jun 05. 2019

    모금신청 6월3일자인데
    아직 렉스가안들어오네요 ㅠ

    EOS REX Person in charge Jun 05. 2019

    안녕하세요. 고객님 6월 3일에 신청해주셨다면 4차 청약 신청해주신 상황이라 오늘 월요일(10일)에 REX가 입금될 예정입니다.

  • dru9 Jun 04. 2019

    청약신청 시점부터 이자가 계산되나요? 아니면 마감 시점부터 계산되나요?

    EOS REX Person in charge Jun 04. 2019

    안녕하세요. 청약신청 후 구매시점이 따로 있습니다. 구매시점부터 상환 시점까지 계산됩니다.

  • dr**** Jun 03. 2019

    목표판매액을 초과해서 입력했다는데 무슨소리죠...

    EOS REX Person in charge Jun 03. 2019

    안녕하세요. 잠시 오류가 발생했던 것 같습니다. 현재는 오류 수정하여 정상적으로 신청가능합니다.

  • hu**** Jun 01. 2019

    이오스렉스 상장은 언제쯤 계획하고 있나요?

    EOS REX Person in charge Jun 01. 2019

    이오스 렉스는 상장과는 무관합니다.

  • ca**** Jun 01. 2019

    상환시간이되면 다시이오스가 들어오는게 맞지요? 사라지는게 아니고

    EOS REX Person in charge Jun 01. 2019

    네 맞습니다. 상환 시점에 다시 이오스로 입금됩니다.

  • 제이미 Jun 01. 2019

    상환후 이오스렉스는 출금이 되는건가요?

    EOS REX Person in charge Jun 01. 2019

    네 맞습니다. 상환은 REX를 다시 EOS로 바꾼 뒤 지급되는 과정이므로 REX가 출금처리되는 것이 맞습니다.

  • 윌라 May 30. 2019

    이메일 온거보니깐 3차 청약해도 피자 에어드랍 지원하는건가요??

    EOS REX Person in charge May 30. 2019

    네 맞습니다. REX 청약 신청하셔도 피자 에어드랍 지원할 수 있도록 변경하였습니다.

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

Bitcoin

BTC

12,328,899.48 KRW 4.04%

Ethereum

ETH

260,379.78 KRW 4.76%

Ripple

XRP

383.36 KRW 2.95%

Litecoin

LTC

115,096.71 KRW 5.18%

Bitcoin Cash

BCH

372,348.14 KRW 5.26%

Binance Coin

BNB

35,373.19 KRW 2.98%

Tether

USDT

1,174.34 KRW 0.72%

EOS

EOS

4,982.82 KRW 4.08%

Bitcoin SV

BSV

196,709.73 KRW 4.72%

TRON

TRX

32.80 KRW 7.19%

Stellar

XLM

105.86 KRW 6.22%

Cardano

ADA

71.00 KRW 6.84%

Monero

XMR

98,717.82 KRW 3.07%

Dash

DASH

137,382.92 KRW 2.93%

NEO

NEO

14,956.32 KRW 7.00%

Ethereum Classic

ETC

7,263.32 KRW 1.79%

Tezos

XTZ

1,233.94 KRW 1.56%

NEM

XEM

78.27 KRW 5.10%

Maker

MKR

661,646.05 KRW 1.55%

Ontology

ONT

1,185.49 KRW 5.61%