Telos Blockchain Network Ba...

We spoke to Douglas Horn, the architect and whitepaper author of the Telos blockchain network, which is built using EOSIO technology.Could you introduce your blockchain network for us?Telos is a public blockchain focused on empowering mass adoption. Our pillars for this makes it easy to join and use Telos, provide powerful tools for app builders to ease their development cycles, and lead the world in functional blockchain governance.We see a world where people are eager for the new field-leveling opportunities that blockchain can bring to individuals and groups-allowing them to better compete with the entrenched powerful elite. To foster this, we are aggressively pushing the boundaries of blockchain user experience and ease of use.We are also giving people a real opportunity to participate in governance, with unique features that support both governance of Telos itself, plus tools for every app on Telos to easily manage its own governance. In fact, we’ve extended the system-level voting and committee management functions to apps so that they don’t have to worry about maintaining the code or providing their own interface-that can be consistent across all Telos apps for the convenience and familiarity of users.Telos has invested heavily in adding tools that extend the capabilities of what app developers can do with blockchain technology. EOSIO itself is one of the biggest elements due to its power, security, and enormous capacity. The governance tools we offer to developers and the decentralized file storage solution we are now rolling out are other examples.What inspired you to create your blockchain network?Telos was launched by a grassroots community that deeply believed in a vision of EOSIO as a technology that enables all users to participate in its growth and evolution. We felt that functions like voting on the direction of the community, resolving disputes among users, and funding future development based on community priorities were not only noble but necessary for the chain’s longevity and advancement.We believed in their importance enough to launch a new EOSIO-based blockchain where we could build all of those tools ourselves so that users would have another option in approaching governance and mass adoption. These concepts are inexorably linked in our minds because how can you have a chain that is truly built for all users if they do not have the opportunity to set its direction?While building these powerful new governance tools, it quickly became clear to us that they would be invaluable to every decentralized autonomous community (DAC) and tokenized economy to come, and that creating a unified set of easy-to-use tools with a common interface was the most user and developer friendly way to give people these tools.Why did you decide to use EOSIO specifically?To me, the development of blockchain tech follows a clear arc towards higher function and greater usability. EOSIO can execute powerful computations every half second which makes it among the fastest blockchain platforms presently available — and perhaps the fastest long term, due to physical limits of global networks. It has proven itself to be able to support large, global scale networks with a variety of users and activities.Of course, this is just one small component, but it’s important because when one invests in a platform within a technology that is still young, like blockchain is, it’s important to know that the technology is tried and tested.We think that businesses and developers will come to this same conclusion and embrace EOSIO as the winner when it comes to pure mechanics. But more importantly, we’ve seen Block.one’s dedication to regularly turning out new features and improvements to the EOSIO reference software. People don’t adequately appreciate how crucial this is because all of the EOSIO-based chains are still under-utilizing their capacity.But Block.one gets it. They are building like the house is on fire because their vision of the immediate future matches our own. As a result, they turn out more new code and capacity improvements in a month than other chains do in a year. EOSIO 2.0 is a great example: We are seeing a 10–16 times improvement in CPU execution times in our testing.What are the challenges you have had to overcome, and how did you do it?Our single largest challenge was building a world class blockchain, requiring a high level of original code development without raising a single dollar in any form of token sale. The early Bitcoin developers had the same challenge, of course, but they did not exist in an environment where exchanges, conferences, advertisers, influencers and everyone else in the ecosystem had all been trained to demand their slice of the pie before engaging with any project. We did.Of course, we had the benefit of Block.one’s ongoing development of EOSIO as our core platform, but Telos needed to support its own core developers to write the code for all of the additional features we promised.In the end, we developed more original, open source additions to the EOSIO code base than any EOSIO-based blockchain, and it was all done without money coming in.All of the functions around promoting the chain, getting listed on exchanges, listing services, attending conferences-these all needed to be approached without the use of any funds. It was extremely challenging.We were fortunate, though, that we had a very committed and accomplished group of contributors. We were aligned in our vision for what Telos could uniquely offer if we could just get through those tough days.Most importantly, we knew that once the chain launched, the worker proposal system we were creating would enable us to have an ongoing source of funding for growing the chain as directed by the token-holders.At this point, this has proven to be true and Telos is now funding exchange listings, marketing, ongoing development, and more through this governance function. We were recently listed by CoinMarketCap and Telos is currently a Top-100 token by market capitalization on services like CoinGecko. The road here was hard but now we have ongoing funding while ICO-based projects look at ever-dwindling coffers.What stage is your blockchain network at?Telos launched its mainnet in December 2018. We perform our own development in adopting EOSIO updates and expanding our own original code. In fact, we passed the 50 million block mark, updated to EOSIO v1.8, including activation of additional features, and we’re now testing the EOSIO 2.0 release candidate.In terms of governance, we have a robust worker proposal system that funds projects for Telos. Some of these projects also benefit the entire EOSIO and blockchain ecosystems such as the Chronicle history project. The WordPress blockchain timestamping plugin, WordProof, which was originally funded by the Telos worker proposal system, lets computer users worldwide prove the publication time of their blog posts on the Telos, EOS, and other EOSIO blockchains.The Telos worker proposal system is actually the only one in the world that can be voted on by all users and is 100% smart contract-controlled. Telos completed our first amendment ballot for our governance, which was also voteable by all users and is smart contract controlled. In fact, we even managed to survive an election hacking attack rather painlessly due to our governance.What are your plans for scaling?We recently passed the Telos Economic Development Plan, which was the historic community-voted governance amendment ballot I mentioned. The community overwhelmingly approved a plan that turns Telos into the first zero-inflation third-generation blockchain by drawing tokens that were never claimed from a pool that had been reserved for EOS snapshot holders whose tokens had been stuck on exchanges. This amendment greatly fuels our ability to scale, in part — by making the chain more attractive to token holders.We’ve made important inroads into user communities in the developing world. Developers on Telos launched the world’s first stable coin pegged to the South African Rand-the leading currency in sub-Saharan Africa-called the eZAR.Other African national currencies are in the process of deploying similar regional stablecoins and this is driving major interest among regional players because there is actually no traditional clearinghouse for these types of transactions amongst African national currencies. So, the trade on Telos’s native DEX, Vapaée, (built on Telos worker proposal system funds!) may become the first free and open exchange platform that these currencies ever see.We are receiving high levels of interest from app developers now who appreciate the features we built for them.A project called Hypha DAO that recently deployed on Telos tells us that the governance tools saved them a year of development time versus building these features on their own. They have brought a number of affiliated projects now who want that same rapid development and platform-level solidity.Other developers are very interested in our decentralized file storage system, dStor, which will empower many functions like document storage, streaming, GDPR compliance and more that are core to their missions. We were able to work with Carbon.money to create direct fiat onramps and offramps to Telos and these are now directly integrated into some Telos wallets like Sqrlwallet.io. So we feel that the investment we’ve made in this development is already starting to pay off.Can you introduce your team and tell us what makes them special?Members of the Top-10 San Francisco EOSIO Hackathon Team (left to right): Marlon Williams (Telos Miami), Peter Bue, Craig Branscom, Ed Silva, Douglas Horn (GoodBlock)Telos is highly decentralized with contributors all over the world.GoodBlock in Seattle took the lead on much of the code development, including the voting and governance features and dStor decentralized file storage.Telos Miami built an advanced wallet for blockchain governance-one that also includes the ability to purchase TLOS tokens or the Telos USD stablecoin from Carbon right in the wallet.EOSza in South Africa built an equally easy to use mobile wallet for Telos that’s in the Apple and Google Play stores and includes all the features for African stablecoins, among other things.Suvi Rinkinen with CryptoSuvi in Finland does an amazing job as president of the Telos Foundation working with businesses, and Richard Bryan of TelosDAC is not only leading the Telos Foundation board and the Telos Blockchain Solutions Ltd. consultancy in London, but is additionally working with onboarding and app deployment efforts in Kenya.We have several strong contributors in Spain such as The Teloscope, eosBarcelona, and Telos Madrid. Several Telos team members maintain a strong presence on other EOSIO chains, helping us maintain strong relationships there, like Infinitybloc, CalEOS, EOS Detroit, EOS Dublin, AtticLab, and EOSphere.We have marketing teams like Team Telos in the US, OktoTelos in Venezuela and a number of others who are all funded by the Telos worker proposal system voted by the users.What makes the Telos community and team special is their commitment to building technology along with a functional and thriving community. Many of us have been with the project from the start, and some others are newer to Telos.Several teams like The Teloscope, CryptoSuvi, EOS USA, and Telos Kitchen came to Telos after our launch but made a real commitment to growing Telos, and as a result quickly came into leadership positions. It’s a real meritocracy and the Telos voters have been quick to reward strong contributors with funding from the worker proposal system or votes as block producers to operate the network.No one can afford to rest on their laurels for long on Telos because there’s always someone new willing to work hard to grow the community because they see that their work will be rewarded. This has created a fantastic work ethic. People will bring a lot of effort and ideas when they know that those will be rewarded.(Left to Right) James Davis, Douglas Horn, and Beth Farnham (GoodBlock), Rob “Robrigo” Konsdorf and Phil Wiszowaty (EOS Detroit), Daniel Lazor (EOS Metal) at Scaling Blockchain conference in San Francisco.What other projects have you partnered with?The Telos Foundation is our body for promoting the chain and allowing us to make deals between professional organizations. That has let us attend and sponsor conferences and other functions.When we attended the Blockchain Expo London this spring, a large number of opportunities for working with enterprise computing companies came to us, but we discovered that we would need a consultancy business in order to really capitalize on these. So, several people on the team launched Telos Blockchain Solutions as a London-based limited company that could provide services to these big corporations. By the time we attended our next big conference in Amsterdam, we were ready.The Telos booth at Blockchain Expo Amsterdam. Ville Sundell and Suvi Rinkinen (CryptoSuvi), Jan Smit (Dutch EOS), and Jim Hewitt (TelosUK) can be seen (left photo l-r; Preparing for the doors to open, manned by Douglas Horn (rt).Telos Blockchain Solutions (TBS) has let us partner with a number of companies, with many more partnerships about to be announced. One of our first strategic partnerships is with Fairwinds Digital in Italy, which has a fantastic platform for IoT devices. Telos, through TBS, is providing technology for interfacing these IoT devices with the Telos blockchain to record data from edge computing devices and trigger smart contract microtransactions based on that data. We are launching new projects soon with some large enterprise companies out of this partnership.We’re excited about the apps and DACs that are deploying on Telos now. Our own ethos seems to be attracting projects that share our interest in egalitarian governance. I’m excited about SEEDS and Hypha DAO, which is a regenerative economy project aiming to align incentives on projects that build a better world. Havuta is a dapp that provides transparency and outcome tracking for international aid programs and NGOs. They came to Telos because it was a great culture fit for what they were building and because the tools Telos provides gets them up and running faster.Gyfte just deployed on Telos and we will be using their identity services to increase transparency for those who need it. The block producers themselves will be early adopters of Gyfte to strengthen our governance around preventing cross-ownership of more than one BP, but we expect many applications to also take advantage of these new features.Where do you see your blockchain network in the future?When people discover that they can collaborate as easily on financial and governance matters as they previously could on spreadsheets and word processing, we will see thousands and thousands of homeowners associations, trade groups, sports leagues, unions, tribes, student groups, and local governments voting freely and easily on their various issues from easy-to-use tools common to all Telos dOrganizations.This will be contagious because once groups start using these, other tools will just seem clumsy, opaque, and out of touch. Their members will bring Telos to the other organizations they’re a part of to improve them. I see people thinking of Telos as the “self-governance blockchain” that organizations turn to in ensuring that their stakeholders are in the driver’s seat.In a sentence, how would do you want readers to remember your blockchain network?Telos is building a future where the individuals are empowered by technology to work together and share both voice and value fairly and transparently so that they can build great things together.Building on EOSIO?Our #BuiltOnEOSIO series showcases some of the amazing projects leveraging EOSIO technology to build a more secure and connected world. If you would like to suggest a project for us to feature please send an email to spotlight@block.one for our Developer Relations team to review.- Block.one Developer Relations teamImportant Note: 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.Telos Blockchain Network Based on EOSIO Technology was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOSIO™ Quickstart Web IDE: ...

Getting started with a new technology always poses challenges. There are often new languages, development patterns to learn, and hardware prerequisites to meet for setting up a development environment. Blockchain development in particular has certain resource requirements that must be met to run a full node, replay a chain, or test smart contracts. These issues present obstacles for new developers who are interested in exploring blockchain technology. As EOSIO grows, we are working to create new tools and libraries that make EOSIO development faster, easier, and more accessible to developers around the world.To that end, a significant goal of our engineering effort is to make it possible for anyone to rapidly deploy their blockchain projects with EOSIO software. The EOSIO Quickstart Web IDE reduces barriers to entry for new developers, so they can get started in minutes, share, and collaborate on EOSIO projects.Currently, building on EOSIO entails a multistep setup process, and a powerful computer to run a full blockchain node. For anyone just getting started, this process begins with installing and configuring EOSIO. After, EOSJS must be installed and configured for developing web applications. It is often difficult to establish a clear workflow as these processes take many steps consisting of numerous components. There is also the issue of computing power; to run a full node requires a computer with at least 16GB of ram, although 32GB or more is recommended, enormous amounts of disk space, and a fast CPU.Reducing Obstacles for Blockchain DevelopersEOSIO 2 introduces alpha support for the EOSIO Quickstart Web IDE, a one-click web-based IDE that runs in a browser and is designed to radically simplify the developer experience. With this new tool, all it takes to start building is a single click to launch a fully functional EOSIO development environment in a browser.The EOSIO Quickstart Web IDE empowers anyone to dive right into programming C++ smart contracts and EOSJS based web applications. This new IDE is integrated with the source code, so a developer can immediately commit any changes they make from demo applications directly into their own personal GitHub. From there, developers may collaborate together in any way they choose. A personal copy of the blockchain is provided along with the ability to quickly edit and modify the included talk.cpp smart contract and the react web-app coded in index.tsx. Once developers fork the source repo, they can setup multi-user push access to their personal forks and enable several developers to collaborate in real-time.Getting started is easy. Simply head to the open-source EOSIO Quickstart Web IDE GitHub repository and follow the accompanying instructions.There are a number of features we’re researching that may be supported by the EOSIO Quickstart Web IDE in the future. These include support for Swift and Java application development, a local Theia based version to secure intellectual property, additional UI features, a table explorer to allow developers to interact with data. Considerations are being made for the integration of web-based block explorers, DEMUX, and History Tools. The EOSIO Quickstart Web IDE is perfect for students studying blockchain, hackathon participants, or new developers learning EOSIO.Stay ConnectedThe EOSIO Quickstart Web IDE is one of many projects from Block.one that benefits from community research, testing, and input. If you would like to offer feedback and work more closely with our team to improve EOSIO for developers, you can send our developer relations team an email at developers@block.one.Stay up-to-date with future announcements, by subscribing to our mailing list on the 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.Important Note: 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.EOSIO™ Quickstart Web IDE: Start Building on EOSIO in Minutes was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introducing EOSIO 2: Enhanc...

EOSIO 2 was built with developers in mind. Our focus: make it faster, simpler, and more secure to build on EOSIO.We believe the single biggest bottleneck for blockchain development is the speed in which they can execute smart contracts.EOSIO was the first blockchain software to use a WebAssembly (WASM) engine to improve performance, but in time, we outgrew existing general purpose WASM engines and knew we could do more.Our solution: build our own, designed from the ground up with blockchain in mind. EOS VM, our purpose-built blockchain WASM engine, runs the EOS Mechanics WASM CPU benchmarks up to 16x faster than Binaryen, which was released with EOSIO 1.0.Next, we wanted to solve the barrier to entry for new developers — those heading to an #eosiohackathon or building on EOSIO for the first time. Typically, setting up a blockchain development environment is a multi-step process that can take hours, even days, to complete. That’s why we’re building the EOSIO Quickstart Web IDE, a development tool that allows new developers to go from start to ready-to-build in minutes.Finally, for any developer, one of the critical pain points to onboarding new users to blockchain applications is safeguarding private and public keys, and the security risks created if done incorrectly. With this release of WebAuthn support for EOSIO, developers can begin testing transaction signing with WebAuthn in their EOSIO applications, providing a level of security for private keys that doesn’t exist in blockchain today.Continue reading for further explanation of the four major components included in the EOSIO 2.0 Release Candidate:EOS VM: A high-performance WebAssembly (WASM) engine specialized for blockchain applications that facilitates more efficient use of system resources when processing smart contracts and substantial performance gains.EOSIO Quickstart Web IDE: A powerful, new, self-contained, web-based integrated development environment for building EOSIO smart contracts and associated web applications. It can be set up in minutes, run in any browser, and helps lower the barrier to entry for new EOSIO blockchain developers.WebAuthn Support: A widely accepted secure authentication standard that enables transaction signing without browser extensions or additional software.Weighted Threshold Multi-Signature Block Production Support: A secure way for block producers to use different keys to sign blocks on primary and backup block production hardware.EOS VMWe have developed a new purpose-built WebAssembly (WASM) engine, called EOS VM, to meet the growing demands of secure deterministic execution on EOSIO blockchains. Although well-suited to their purposes, Binaryen and WABT interpreters have issues with unbounded memory allocation, protracted loading time, and stack overflows, and they lack a sandbox on runtimes. Combined, these issues curb overall performance and reliability.As an initial WASM solution, the Binaryen interpreter was released in June 2018 with EOSIO 1.0, and it was replaced in September that year with EOSIO 1.3’s support for WABT, offering a 2x performance gain. With EOSIO 2, we’re releasing a new WASM engine called EOS VM, comprised of three components, each with its own features and offering specific performance enhancements.A Trio of Powerful Components for Blockchain WebAssembly ExecutionThe EOS VM Interpreter is a WebAssembly interpreter providing extremely fast parsing/loading, and deterministic and efficient time bound execution. Designing the interpreter from the ground up has enabled us to make room for future debugging support for smart contracts.The EOS VM Just In Time (JIT) compiler is a WebAssembly compiler that takes WASM and generates native code on the fly. This architecture enables very fast execution of WASM smart contracts and provides significant performance benefits over interpreters like WABT, Binaryen, and the EOS VM Interpreter. The sheer speed of this JIT solution allows us to use it on the blockchain without the long block compiling times of other solutions.The EOS VM Optimized Compiler is the third component of EOS VM and it uses a specialized compiler framework (LLVM) that leverages a multipass compilation architecture. The resulting native code from the Optimized Compiler is often an order of magnitude faster than the same code executed within WABT, Binaryen, EOS VM Interpreter, and EOS VM JIT. Most importantly, it is even faster than the existing WAVM engine, but unlike WAVM it can be used safely on the blockchain utilizing our tier-up design.Extremely Fast ExecutionOur benchmarking for the different components produced the following performance enhancements in our test environments:1 EOS Mechanics Benchmarks were sourced from the EOSIO community authored benchmarks and were run on AWS z1d.metal instances. 2 Replay benchmarks compared the time it takes for the EOSIO system provided replay capability to complete the same replay on the noted WASM engines and were executed on AWS z1d.metal instances.The above performance benchmarks show the relative strengths of various EOS VM components. EOSIO 2 features EOS VM JIT as the front line compiler for most smart contract execution, while the EOS VM Optimized Compiler attempts to compile the same smart contract in the background and deploy it for extremely fast subsequent execution on the chain. This tier-up architecture enables EOSIO 2 to leverage both fast startup and optimized compilation of smart contract code.EOS VM and its components are also highly customizable, so developers can implement its various facets in a specific manner suited to their desired functionality. Learn more by referring to the EOS VM repository on GitHub.Significant Improvements to Network CodeWe have added multi-threading support to net_plugin. Almost all the processing in the net_plugin, including block propagation, transaction processing, block/transaction packing/unpacking, and other processes are now handled by separate threads that are distinct from the main application thread. By isolating these processes we have seen significant improvements in transaction processing and block processing performance on multi-producer EOSIO networks. More details are available in the EOSIO 2.0.0-rc1 release notes.EOSIO Quickstart Web IDEEnhancements in EOSIO 2 were made with developers in mind, and this new tool will make it much easier to get started, share, and collaborate on EOSIO projects.Setting up a development environment for EOSIO currently entails a multi-step process, run locally on the developer’s computer, that may be quite complicated for those who are just onboarding. Now in the alpha support stage, the EOSIO Quickstart Web IDE intends to remove barriers to entry for developers. Run in the cloud, it enables new developers to set up a smart contract and web app development environment along with a fully integrated single-node personal testnet, so they can go from getting started to building in minutes.The EOSIO Quickstart Web IDE makes EOSIO more accessible to new blockchain developers, simplifying the process and making it quick and easy to start learning EOSIO development. Developers can begin with demo applications, seamlessly make changes, and see updates in real-time, as well as commit code to git repositories right from the browser.We look forward to receiving feedback from the community as new developers start building with the EOSIO Quickstart Web IDE.WebAuthn Support for EOSIOWebAuthn is a standard for strong user authentication collaborated on by the World Wide Web Consortium (W3C), the Fast Identity Online (FIDO) Alliance, with help from Google, Mozilla, Microsoft, Yubico, and others. WebAuthn allows you to use a hardware device for authenticating and signing transactions in a browser without extensions or other software installed on your device.WebAuthn creates cryptographic key pairs on devices like a YubiKey and shares only the public key with a remote server over a secure and authenticated channel. By managing authentication credentials entirely within hardware devices, WebAuthn has been shown to essentially mitigate entire classes of attacks such as phishing. Since the hardware device is essential, and passwords are not stored on a central server, implementing WebAuthn-based authentication can even help prevent high-profile data breaches where passwords are stolen.With this release of WebAuthn support for EOSIO, developers can begin testing transaction signing with WebAuthn in their EOSIO applications. EOSIO support for WebAuthn is a step towards secure and seamless transaction signing without needing to keep track of private keys or other account information. We are continuing to investigate mechanisms to support both community-facing and enterprise-level participants who wish to adapt their applications for WebAuthn integration, and we encourage application developers to join the first wave of early adopters testing the private applications of this technology.Weighted Threshold Multi-Signature Block ProductionBlock producers must be able to provide high availability for their core service of running the blockchain. A common approach to achieve this is redundant infrastructure that efficiently maintains block production in the event of a hardware malfunction or networking issues. Weighted Threshold Multi-Signature Block Production is the first of many features that seek to provide block producers with a complete, high-availability solution.Current consensus rules require exactly one cryptographic block signing key per block producer. This key, whether stored on disk and loaded via software or protected with a hardware wallet, represents a single point of failure for the operations of a block producer. If that key is lost or access to the hardware module that contains it is temporarily unavailable, the block producer has no choice but to drop blocks, impacting the whole network’s throughput.To improve the security and scalability of block production, weighted threshold multi-signature block support provides a permission layer that allows for multiple block signing keys in a flexible scheme that will enable redundant block signing infrastructure to exist without sharing any sensitive data. Read more about weighted threshold multi-signature block production on GitHub.Stay ConnectedWe continue to regularly iterate new features into the EOSIO software suite to provide developers access to higher-performing software enhancements, a secure means of transaction signing, and robust authentication protocols. Community participation is encouraged, as feedback provides insight into the specific needs of developers. If you would like to offer feedback on the release candidate of EOSIO 2 and work more closely with our team to improve EOSIO for developers, you can contact our developer relations team at developers@block.one.To keep up-to-date with future announcements, you can also subscribe to our mailing list on the 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.Important Note: 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.Introducing EOSIO 2: Enhancing Performance, Improving Security, and New Developer Tools was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Maturing EOSIO Resource All...

EOSIO provides a wide range of options for allocating the available CPU and network bandwidth among token holders. The underlying principle of EOSIO is that if you own 1% of the tokens you may utilize 1% of the available bandwidth. Following this principle we created the resource exchange contract, known as REX, which allows token owners to rent their bandwidth to others at a market rate.With the advent of EOSIO 1.8, it is now possible for a contract owner to pay for the CPU and network bandwidth of their users by co-signing the transaction. Applications are now able to rent resources from REX and then cover bandwidth for users by cosigning their transactions. Under this model users no longer have to worry about bandwidth resources. This model is similar to how companies can choose to either buy hardware or lease it from cloud services, while simultaneously enabling companies to subsidize the bandwidth requirements of their customers.In addition to the above two ways to gain access to bandwidth on EOSIO networks, allocated, but unused, bandwidth can be freely used by others proportional to their tokens. This is like an internet service provider having a minimum guaranteed bandwidth, but allowing you higher speeds when the network is not congested.The Debate over Allocation of Free ResourcesSome users of EOSIO public blockchains, such as EOS, have come to count on “free bandwidth” like someone renting cheap AWS spot instances. Eventually, someone bids up the spot instances and their “cheap” service is cut off unexpectedly. This is what happens when someone rents tokens from the REX and then utilizes the available “free extra capacity” to bring the cost of “spot instances” beyond what many accounts have provisioned. An account may only have a guarantee of 1ms per day, but be relying upon 1000ms per day typically available while the network load is low. If usage increases and their “average daily use” is over 1ms then the account is frozen until they rent or buy more tokens.It is critical to point out that “congested mode” simply means the end of “free surplus bandwidth”. Even while in “congested mode”, someone with 1% of the tokens can continue to transact uninterrupted so long as their average consumption remains below 1%.In an effort to reduce costs for end users, while the network is idle, someone with a limited amount of bandwidth, could in fact consume a greater amount of bandwidth. However, once traffic on the network picks up, users will still operate without interruption as long they only consume the percentage of bandwidth they’re allocated for.A typical transfer consumes about 188us of CPU today, and with EOS VM that number could fall substantially. On EOS for instance, this means that we can expect spending 1 EOS/month on REX enables someone to perform 100,000 transfers per month.For example, at $3 per EOS the result is $0.00003 per transfer which is relatively very inexpensive even when the network is experiencing high volumes of traffic. Note that the cost to rent EOS would likely increase if the network remains highly utilized and everyone rented what they needed instead of relying on free bandwidth.Some users have taken it upon themselves to wastefully consume the “free” bandwidth offered when those who have reserved bandwidth don’t utilize it. This behavior forces the network to reduce the amount of “free” bandwidth it offers to all users, and disrupts those that have come to rely on a consistency of free resources.Bandwidth Allocation on EOSIO Public BlockchainsEOSIO can offer “free” transactions in two senses. Firstly, when you own tokens you don’t consume tokens while transacting. This kind of “free” transacting is paid for through token inflation. The second is the surplus of network resources that have historically been offered to the public for free, beyond the minimum guarantee. It is this second kind of free transaction that can, and we believe should be phased out.In EOS’s case, we believe it’s now time to operate the network as if it is experiencing high volumes all the time. This wasn’t possible before the REX because capital costs to transact “for free” would have been too high, but with the existence of the REX and EOSIO 1.8, it is now cheap enough to rent network resources, and giving free bandwidth during low volume times is no longer necessary or beneficial for optimal network operation.Recent events have evidenced that the existence of “sometimes free” bandwidth creates unrealistic expectations in both developers and users who don’t fully understand the specifics of EOSIO design. Removing this feature will ensure everyone adapts to securing network resources through renting or staking tokens, and will result in an improved user experience where every user always gets what they expect.Benefits to REXElimination of “free surplus bandwidth” will result in more predictable network pricing. Currently free bandwidth is “undercutting” the REX market, and by eliminating free usage, and the unrealistic expectation of an infinite supply of such, people will be required to pay for the bandwidth they are using, and all bandwidth will be allocated to applications and users that have secured it. The net result will be a more fair outcome for those renting resources to REX, more value driven back to token holders, and most importantly, a more stable and predictable network state.Grey Listing as an Interim SolutionEOSIO currently supports an option for block producers to “grey list” accounts that abuse the free bandwidth feature by restricting them to their guaranteed bandwidth allocation. This greylist feature was added in the early versions of EOSIO to limit those who would abuse the system without blocking them entirely. This is a subjective feature, which means that it is not a hard fork and block producer adoption will effect the rule on a pro-rata basis; Block.one recommends that block producers leverage this feature.In the meantime, and as an additional measure, Block.one is working on a new feature for EOSIO that will allow block producers to specify a grey list value which would apply the grey list to all accounts by adjusting the maximum “free bandwidth multiple” to a value between 1000x and 1x. The goal is to provide a way for block producers to gradually reduce the free bandwidth multiple, as the network moves to a more more modern resource allocation patterns. Block.one believes that a hard fork could be used as another effective measure to make the shade of grey listing a global consensus parameter, rather than a setting individually implemented by each block producer.ConclusionThe EOS network is an example of a public blockchain that continues to successfully operate according to EOSIO’s design, and everyone is fairly getting their share of available network resources. The advent of REX and EOSIO 1.8 now eliminates the need to offer free bandwidth during uncongested mode in order to keep bandwidth costs extremely low. The maturation of public blockchains running on EOSIO to allocate network resources solely to “staked” participants will introduce stability and predictability in line with proven best-practice models for network and hosting resource allocation.Important Note: 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.Maturing EOSIO Resource Allocation for Public Blockchain Usage was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lamington Simplifies EOSIO ...

Kevin Brown, the founder of Coinage, tells us about his work on the Lamington project and how this tool is designed to help compile, deploy and test EOSIO smart contracts.How does Lamington aid in smart contract development?Lamington is an easier way to compile, test, deploy, and call actions on your EOSIO smart contracts from Javascript and Typescript. It generates full Typescript types from your ABIs (giving you autocomplete in VSCode even if you don’t use Typescript) and creates contract objects so you can simply write await contract.action(parameter1, parameter2) instead of having to dive down to the EOSIO level on every call. It also comes with a bunch of helpers for asserting data in tables looks how it should after actions are called, or asserting that a contract action is missing an authority, etc.Why did you decide to create Lamington?At Coinage we work with companies to build decentralized platforms at scale every day. When building layer 2 solutions and dApps on EOSIO we realized we kept creating the same shell scripts over and over again, and that there was no easy drop-in way to compile, deploy, and test our smart contracts. When looking at the field of tooling that’s already out there, everything we tried either put constraints on our project (for example, using one smart contract only), didn’t work with our preferred language, or supported Javascript but not Typescript.We wanted a single tool that would get out of the way and just let us write test files next to our contracts. It also turned out to be incredibly helpful to provide a higher level interface so calling actions or get table rows didn’t involve remembering how EOSIO calls worked, but instead just let us call contract.table() or contract.action(), and assertRowsEqual() or assertMissingAuthority().How does Lamington help EOSIO developers?Lamington manages the compilation, deployment, testing, and calling of actions / getTableRows so you don’t have to. When testing it allows you to easily deploy clean copies of your contract so your tests don’t depend on context from each other. When in production it gives you an easy, type aware interface to your contracts, both in calling their actions, as well as retrieving their data with getTableRows.What are the future plans for Lamington? Are you working on any particular new features?It’s still pretty early, so our primary goal at this stage is to get more users using it so we can iron out the bugs and release a v1. Coinage is already using Lamington in production, so we know it works well for our use case, but we want to make sure any nasty edge cases are found and eliminated before we give it a production version number. From there we want to introduce some incremental improvements to the way we help users manage things like eosio.code permission and other more advanced use cases. We want to continue to use the guides section on our website to cover more advanced EOSIO concepts with full examples to help people become better EOSIO developers and dive more in depth than the official documentation.What has the response of users/the community been?It’s been fantastic! One stand out community example for Lamington has been Mitch Pierias. He built a repository of more advanced EOSIO examples which he didn’t have a good way to demo or test before he found Lamington. He’s now rolled Lamington tests out for all of the examples, which helped us to work out some edge cases we hadn’t encountered in our own projects. On the repo there’s now a test suite next to each contract which shows users not just how the C++ looks, but also how they use the actions to actually achieve the functionality demonstrated in the example. He’s now a core Lamington contributor and has moved the tool forward in amazing ways.We’re really looking forward to more interactions with the community to help make Lamington even more valuable for a wider group of developers.Who is working on the Lamington project?Lamington is being funded by Coinage, but it is an open source community project, so the answer to that question is whoever wants to! Our hope is to make Lamington useful enough to a wide enough group of people that we’re able to make EOSIO development more accessible to engineers from any background, and to make EOSIO development more productive for those that are already familiar with it.How are you measuring community feedback to the project?Right now everything is very anecdotal as it’s early days, but our approach is to focus on making a tool where easy things are easy, and complicated things are achievable with some research. Our next key metric for the success of the project is adoption and a v1 release.How do developers get started when using Lamington?Lamington largely fits in with whatever folder structure you’re already using. You can get started by installing Lamington, then following the getting started guide on our website. We also have full API documentation, and if you want to chat with the core team directly, there’s a Slack instance which is open for anyone to join.Do you have plans to make any other development tools in future?We plan to extend Lamington to be as useful as it can be in dApp development. That means making it easier to take on-chain data and show it in React or Vue applications, as well as providing a more robust approach to key management and calling smart contract actions from NodeJS. We’re looking forward to seeing what features are most wanted by the rest of the EOSIO development community.As for other tools, we build tools as we see a need for them, so right now the focus is on making Lamington rock solid, and in the future we may build other tools that help us deliver on our mission of building decentralised platforms at scale.Where can developers go to discuss Lamington and contribute to the project?The best place to chat with the core team to ask questions or generally give us feedback is on the Lamington Slack instance. The best place to contribute issues or pull requests is GitHub.Building on EOSIO?Our #BuiltOnEOSIO series showcases some of the amazing projects leveraging EOSIO technology to build a more secure and connected world. If you would like to suggest a project for us to feature please send an email to spotlight@block.one for our Developer Relations team to review.Block.one Developer Relations teamImportant Note: 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 eos.io.Lamington Simplifies EOSIO Smart Contract Development was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lamington Simplifies EOSIO ...

Kevin Brown, the founder of Coinage, tells us about his work on the Lamington project and how this tool is designed to help compile, deploy and test EOSIO smart contracts.How does Lamington aid in smart contract development?Lamington is an easier way to compile, test, deploy, and call actions on your EOSIO smart contracts from Javascript and Typescript. It generates full Typescript types from your ABIs (giving you autocomplete in VSCode even if you don’t use Typescript) and creates contract objects so you can simply write await contract.action(parameter1, parameter2) instead of having to dive down to the EOSIO level on every call. It also comes with a bunch of helpers for asserting data in tables looks how it should after actions are called, or asserting that a contract action is missing an authority, etc.Why did you decide to create Lamington?At Coinage we work with companies to build decentralized platforms at scale every day. When building layer 2 solutions and dApps on EOSIO we realized we kept creating the same shell scripts over and over again, and that there was no easy drop-in way to compile, deploy, and test our smart contracts. When looking at the field of tooling that’s already out there, everything we tried either put constraints on our project (for example, using one smart contract only), didn’t work with our preferred language, or supported Javascript but not Typescript.We wanted a single tool that would get out of the way and just let us write test files next to our contracts. It also turned out to be incredibly helpful to provide a higher level interface so calling actions or get table rows didn’t involve remembering how EOSIO calls worked, but instead just let us call contract.table() or contract.action(), and assertRowsEqual() or assertMissingAuthority().How does Lamington help EOSIO developers?Lamington manages the compilation, deployment, testing, and calling of actions / getTableRows so you don’t have to. When testing it allows you to easily deploy clean copies of your contract so your tests don’t depend on context from each other. When in production it gives you an easy, type aware interface to your contracts, both in calling their actions, as well as retrieving their data with getTableRows.What are the future plans for Lamington? Are you working on any particular new features?It’s still pretty early, so our primary goal at this stage is to get more users using it so we can iron out the bugs and release a v1. Coinage is already using Lamington in production, so we know it works well for our use case, but we want to make sure any nasty edge cases are found and eliminated before we give it a production version number. From there we want to introduce some incremental improvements to the way we help users manage things like eosio.code permission and other more advanced use cases. We want to continue to use the guides section on our website to cover more advanced EOSIO concepts with full examples to help people become better EOSIO developers and dive more in depth than the official documentation.What has the response of users/the community been?It’s been fantastic! One stand out community example for Lamington has been Mitch Pierias. He built a repository of more advanced EOSIO examples which he didn’t have a good way to demo or test before he found Lamington. He’s now rolled Lamington tests out for all of the examples, which helped us to work out some edge cases we hadn’t encountered in our own projects. On the repo there’s now a test suite next to each contract which shows users not just how the C++ looks, but also how they use the actions to actually achieve the functionality demonstrated in the example. He’s now a core Lamington contributor and has moved the tool forward in amazing ways.We’re really looking forward to more interactions with the community to help make Lamington even more valuable for a wider group of developers.Who is working on the Lamington project?Lamington is being funded by Coinage, but it is an open source community project, so the answer to that question is whoever wants to! Our hope is to make Lamington useful enough to a wide enough group of people that we’re able to make EOSIO development more accessible to engineers from any background, and to make EOSIO development more productive for those that are already familiar with it.How are you measuring community feedback to the project?Right now everything is very anecdotal as it’s early days, but our approach is to focus on making a tool where easy things are easy, and complicated things are achievable with some research. Our next key metric for the success of the project is adoption and a v1 release.How do developers get started when using Lamington?Lamington largely fits in with whatever folder structure you’re already using. You can get started by installing Lamington, then following the getting started guide on our website. We also have full API documentation, and if you want to chat with the core team directly, there’s a Slack instance which is open for anyone to join.Do you have plans to make any other development tools in future?We plan to extend Lamington to be as useful as it can be in dApp development. That means making it easier to take on-chain data and show it in React or Vue applications, as well as providing a more robust approach to key management and calling smart contract actions from NodeJS. We’re looking forward to seeing what features are most wanted by the rest of the EOSIO development community.As for other tools, we build tools as we see a need for them, so right now the focus is on making Lamington rock solid, and in the future we may build other tools that help us deliver on our mission of building decentralised platforms at scale.Where can developers go to discuss Lamington and contribute to the project?The best place to chat with the core team to ask questions or generally give us feedback is on the Lamington Slack instance. The best place to contribute issues or pull requests is GitHub.Building on EOSIO?Our #BuiltOnEOSIO series showcases some of the amazing projects leveraging EOSIO technology to build a more secure and connected world. If you would like to suggest a project for us to feature please send an email to spotlight@block.one for our Developer Relations team to review.Block.one Developer Relations teamImportant Note: 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 eos.io.Lamington Simplifies EOSIO Smart Contract Development was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Upland Blurs the Boundaries...

Upland Co-Founder Idan Zuckerman explains how Upland, a blockchain collectible game, allows players to truly own virtual objects that are linked to the real world, and how this could disrupt the casual gaming industry.Can you introduce Upland for us?Upland is a fun, blockchain-powered, property collectibles game that blurs the boundaries between the real and virtual world. We believe Upland has the ability to spearhead a new type of movement; we call it the Ownership Revolution. People who play Upland can experience true ownership of the digital assets they collect in the game, with provable scarcity and ownership supported by blockchain technology.Where did the initial idea for Upland come from?As friends combining decades of experience in both the casual gaming and decentralized economies industries, we were looking at the different ways blockchain technology can disrupt a $50B casual games industry.One game night, after playing Monopoly and watching the Netflix series “Stranger Things,” we got thinking about a property game in a parallel universe.We believe properties that are based on real-world addresses are the ideal collectible NFT, and can serve as the foundation for a phenomenal location-based game. We knew we’d need to make the game super easy and accessible to play in order to be successful with mainstream audiences, which is why we’ve opted for a unique approach to blockchain gaming by reducing the traditional technical barriers to entry.Can you introduce the team behind Upland, and tell us what makes it special?We have a very diverse team and our founders are serial entrepreneurs from various business and technology backgrounds.My own background is in heading up product and engineering organizations. I started my career in a special tech unit in the IDF (Israel Defense Force) where I led the developer and IT teams. After shifting to Consumer Internet, I also served as the VP of Engineering for Israel’s largest sports-news website, prior to joining the founding team of RocketPlay. I went on to serve as VP of Interactive Product at AGS for 3 additional years.Dirk Lueth co-founded European and US-based companies in the FinTech and digital media spaces, including the Financial Times Deutschland and Forbatec which has been acquired by SunGard (today NYSE:FIS). Dirk has also mentored over 30 startups through his work at the German and Swiss startup accelerators in Silicon Valley and is a frequent speaker/panelist about blockchain and platform economics. He has studied Business Administration in Frankfurt and Paris and received a Ph.D. from the European Business School in Germany, where he wrote his doctoral thesis about private and state-controlled currencies.Mani Honigstein studied at the University of London and Harvard University before starting his tech career in Tel Aviv, Israel where he spent over 10 years. Mani was a Principal at Pitango Venture Capital, Israel’s largest VC before founding and serving as the CEO of RocketPlay. RocketPlay became a leading mobile gaming company before its acquisition by AGS (NYSE: AGS). While serving as the GM of Interactive at AGS, Mani also became a co-founder of Maxwell Financial Labs, a leader in mortgage software. After leaving AGS, Mani started NeueCapital, a venture fund which focuses on investing in European and Israeli B2B software companies.We also have an experienced team of developers in Ukraine, who are dedicated to making the Upland experience exciting, memorable, and addictively-fun for all players.What stage is Upland at currently, and what are your plans for scaling?Upland is currently in the beta phase and we are inviting a limited number of users to test our pre-launch version. San Francisco will be the first city in the game and we plan to expand to other cities and urban areas globally using a franchise system, where local operators can launch Upland in their part of the world. In the future, we also plan to invite third-party developers to build exciting new features and expand on our current foundations.Why did you decide to use blockchain technology, and specifically EOSIO?We decided to use blockchain technology because it allows us to create a real and open economy for our users. Thanks to blockchain technology, players can collect digital properties (NFTs) and virtual currency in the game and truly own them. The in-game currency, UPX, works as a vessel for a trustless exchange of value among our players.We chose to build on EOSIO because we believe it’s the fastest and most scalable blockchain to build Upland on. Our end users don’t have to pay fees to interact with the game and EOSIO has a vibrant and growing community which we are proud to be a part of.How has the EOSIO Community responded to your project?We’ve had some incredible feedback so far from the pool of testers who’ve tried the pre-launch version. The community is very excited to see our finished product, and we have received a lot of interest both in the US and overseas in Asia, so we are optimistic that Upland will be incredibly popular leading up to our full launch later this year.We have opened our waitlist at https://upland.me/ and are inviting limited amounts of users to test and purchase virtual properties in San Francisco.What features of Upland do you think are the most compelling for users?Firstly, we believe Upland’s fun game loops will be a key element for our users. Discovery and interaction is at the core of the game, and the ability to roam the neighbourhood while building a real digital property portfolio is an enticing prospect.Secondly, we have an awesome game hero, The Llama, who helps our players to navigate the new world and truly embodies Upland’s quirky essence.Finally, the core element of Upland is the level of true ownership that blockchain gaming offers. You can purchase, trade, and win items within a game. Blockchain backed assets allow you to truly own and keep your hard earned rewards instead of leaving them in the hands of a gaming company.We also have lots of exciting location-based features planned for the future, one of which is an AR roaming feature, allowing Uplanders to find properties and UPX coins using their mobile phone camera.What makes Upland different from other mobile games out there?Upland is different to other mobile games because it has a natural scarcity of available properties, as they are all based on real-world addresses. We really liked the idea that players can buy a virtual property based on the real world because it’s something people can relate to, either because they want to own what they possess or aspire to in real life, or they simply want to enjoy playing the game.We have also worked hard to make the complex technicalities of the underlying blockchain technology invisible to the player, and to make the game accessible to play using fiat currency for both acquiring and selling assets.We are eliminating the traditional barriers which typically stop people entering the blockchain space, like setting up a crypto wallet. We have simplified our sign-up process, so players only need their email address to get started and there is no complicated key handling when they join.What is the vision for Upland going forward?Our ultimate mission is to bring the benefits of blockchain technology to the mass market, and we aim to do that through the casual gamified experience which Upland offers. We hope one day to see Upland in every city of the world, and to be recognized as a mainstream movement which empowering digital ownership.The Ownership Revolution is coming…Building on EOSIO?Our #BuiltOnEOSIO series showcases some of the amazing projects leveraging EOSIO technology to build a more secure and connected world. If you would like to suggest a project for us to feature please send an email to spotlight@block.one for our Developer Relations team to review- Block.one Developer Relations teamImportant Note: 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.Upland Blurs the Boundaries of the Real and Virtual Worlds was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOSIO™ History Tools: Scali...

By nature, blockchain databases are always growing. With the confirmation of each new block, the ledger of sequential transactions becomes ever longer. An active blockchain’s database can easily grow beyond terabytes in size within years and its entire history must always be preserved.While flexible and scalable access to historical blockchain data is a basic necessity for many blockchain applications, it remains one of the more difficult challenges for blockchain platforms to efficiently deliver. Because a blockchain’s history is so large, applications that require access to historical data are often resource intensive and require special tooling for developers to create performant solutions.In the ongoing effort to improve tools available to EOSIO developers, a stable version of the State History Plugin was released as part of EOSIO Version 1.8 at the end of June. This new solution for history replaced the prior history_plugin and MongoDB Plugin enabling more efficient and scalable access to on-chain data. Additionally, today we are introducing alpha support for a new and more robust blockchain history tool based on RocksDB that will replace the alpha release supporting LMDB that was initially included in History Tools. Support for PostgreSQL within History Tools will continue.This article provides an overview of blockchain history solutions on EOSIO and a simplified architecture diagram explaining tools available for application developers.We’ve had multiple breakthroughs during our ongoing work to optimize history solutions for EOSIO blockchains. Today’s history tools are built to facilitate highly performant searches, written in C++, that can efficiently and scalably sift through terabytes of data from the full history of EOSIO blockchains. As more efficient tools have become available, we’ve deprecated older and now less effective history solutions. This includes the history_plugin that was deprecated with the announcement of EOSIO Version 1.2 and the recently deprecated MongoDB Plugin.The History of State History Tools on EOSIOThe original history_plugin solution stored data in memory, or RAM, which meant that as the chain grew, the amount of RAM needed also grew. Using RAM to service history became an expensive solution, so a more scalable approach took the form of the MongoDB Plugin.By converting raw binary data from the EOSIO blockchain into JSON format and storing this information on disk, the MongoDB Plugin transitioned away from using RAM to using disk, a more cost effective solution. However, this approach also quickly presented scalability issues and as the database grew in size it suffered from decreased performance from being stored as JSON plain text. MongoDB was also very tightly integrated with Nodeos leading to overall stability concerns as the solution evolved.For future reference, a full list of past and future intended deprecations in EOSIO is available here in Github.A Scalable Solution: The State History PluginThe State History Plugin is the latest history solution supported for Nodeos and has been well received across the EOSIO developer community. It acts as a firehose, piping EOSIO blockchain data through an application developer’s preferred history tool for use in their application database. With the State History Plugin, it is possible for any external process to track on-chain data including tables, transaction history, and blocks. This data can, in turn, be stored, transformed, or indexed to suit a variety of needs. The plugin also stores data in portable files, which block producers may distribute alongside snapshots to reduce the time it takes to bring up a new Nodeos instance with a complete state history.The State History Plugin allows developers to request only data that is irreversible to be provided to the consumer, regardless of the mode Nodeos is operating in. Relying on this factor, developers won’t need to implement logic in their applications to see if transactions need to be rolled back as a result of acting on data that was not finalized. This provides relative confidence to developers as to the validity of data from the State History Plugin. For example, it is useful in the case of exchange operators or any other platform or service where operation hinges on transaction finality.Decoupling Nodeos from Access to State HistoryThe State History Plugin meshes with Nodeos without being so tightly integrated that it causes instability. It provides the data via a web-socket, allowing various history tools to hone in on particular data of interest, and populate databases of a developer’s choice accordingly.Using the State History Plugin, developers no longer need to write a tightly integrated plugin into Nodeos to reliably get access to history data. It becomes the mechanism through which finalized blockchain events are published. Now developers can write applications and infrastructure that only need to rely on consuming data from the State History Plugin. Developers can fully control the filtering and transformation of data their applications require.The State History Plugin overcomes limitations present in the MongoDB model and offers a new architecture to developers that supports PostgreSQL and RocksDB.History Tools Integrating with the State History PluginThe State History Plugin works in conjunction with history tools designed to populate developer specified databases by managing full history from the EOSIO blockchain. Once a database is populated, a highly performant search tool, WASM-Query Language (WASM-QL), assists with querying the binary contract data in a scalable way. WASM-QL ships data so that developers can access and query what they need from the database.WASM-QL’s performant query mechanisms allow for scalable full-history queries. WASM-QL has two components. One component runs in the client browser inside a JavaScript application, the second runs on the server nearby the database. This close proximity to the database makes it possible for developers to more efficiently utilize and query the data using pre-defined queries written by the smart contract developers. Once deserialized, the data stored in binary is more accessible to applications and may be efficiently transmitted between the client WASM and the browser application.Simplified History Solution Architecture DiagramRocksDB Alpha in History ToolsWith the addition of alpha support for RocksDB in History Tools, we are moving away from supporting LMDB which was introduced in the initial alpha of History Tools. LMDB presented an option for developers to quickly instantiate a database with less overhead needed for maintenance with a PostgreSQL database, however it was best suited for testing and not ideal for production scale.RocksDB represents a more robust state history database solution for EOSIO blockchain application developers. RocksDB is a versatile embedded database that is not only more efficient, but also simpler to administer than a database server.Applications such as combo-rocksdb, fill-rocksdb, and wasm-ql-rocksdb, offer identical functionality of tools used to store and retrieve data from a PostgreSQL database:combo-rocksdb: Fills the database and answers queries of a live databasefill-rocksdb: Used to initially populate the database but cannot answer queries; once caught up with the chain, switch to combo-rocksdbwasm-ql-rocksdb: Queries a database that isn’t being filledCurrently, RocksDB outperforms LMDB and PostgreSQL databases by considerable margins for both partial and full blockchain history on EOSIO blockchains. RocksDB also stores the full history much more efficiently than PostgreSQL.We are continuing to examine open source solutions for querying state history, and additional solutions will be released under the history tools repository. As the EOSIO ecosystem continues to expand, we are dedicated to pioneering new and effective methods of managing state history for EOSIO blockchains.Stay ConnectedBuilding components of the EOSIO ecosystem is strengthened by support from the EOSIO developer community. We expect to iterate and evolve history tools as they are used and input is received. If you would like to offer feedback and work more closely with our team to improve EOSIO for developers, you can send our developer relations team an email at developers@block.one.To keep up-to-date with future announcements, you can also subscribe to our mailing list on the 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.Important Note: 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.EOSIO™ History Tools: Scaling Access to Blockchain History Data was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

WordProof Puts Content Trus...

Developed by Sebastiaan van der Lans, WordProof represents a powerful toolkit that provides answers to age-old industry problems. By leveraging his expertise and experience with WordPress — open source content management software empowering 34.5% of the web — and merging it with EOSIO blockchain technology, their tools have the potential to improve the security and accountability of internet content by introducing trusted timestamping for hundreds of millions of users.How would you describe WordProof?WordProof is bringing the benefits of blockchain to the world of content, empowering consumers and content creators with the tools to build a safer and more trustworthy internet, starting with WordPress, which powers over one-third of the internet today.The internet has deep-rooted problems that grow daily: distrust, plagiarism, and fake news. We want to create a new standard for a more reliable and trustworthy internet, with the help of EOSIO blockchain technology.WordPress already powers more than a third of all webpages on the internet, which makes it a natural and impactful starting point to bring the benefits of EOSIO blockchain technology to millions of websites and hundreds of millions of users.Our first solution, Wordproof Timestamp, achieves this by allowing content creators to claim ownership and show transparency regarding alterations of their content. Website visitors can then do their own due diligence to determine who owns the content, and if they can be held accountable.Discerning ownership and accountability, combined with trusted timestamping, enables more trust online, and in turn, a more reliable internet.After launching the WordProof Timestamp for WordPress plugins, WordProof has started to work on supporting non-WordPress websites as well.Both WordPress-websites and non-WordPress websites can use the We Stamp For You- service, which automatically timestamps all content in the background.Editors and website-owners no longer need to be able to manage keys and operate a blockchain wallet to experience the power of blockchain.https://medium.com/media/eaedf64fa2229e4ad298fa914a47c44c/hrefWhat inspired you to create WordProof?We have worked with WordPress software for many years, and we think that its success comes mostly from its strong and diverse community.Open source software (like WordPress) allows people to coalesce around concepts and projects in a powerful and unique way. Blockchain technology shares these ideals with WordPress, and EOSIO features one of the strongest and most positive communities.We hope to use EOSIO technology and bring the openness and transparency of WordPress to everything else in the world.Can you introduce your team and tell us what makes it special?Sebastiaan van der Lans, Founder: A successful entrepreneur with a proven background in open-source software, he is the founder of the first and biggest Dutch WordPress agency Van Ons (2006), which created the WordPress GDPR Compliance plugin (100K active users, 1.2M downloads). Now he aims to bring WordPress to the blockchain.Marijn Bent, Development: A developer with experience in both WordPress and blockchain platforms. Marjin wants to lay the foundations for a new internet. Sebastiaan and Marijn have been working together since 2016 on several innovative products at Van Ons.Jelle van der Schoot, Product: He founded the biggest Dutch blog about WordPress at a young age and authored a book about it. Today he dreams of the public using the power of blockchain technology, especially people who are not tech-savvy.Frank van Dalen, Head of Business: After an education in IT, Frank started his career at Procter & Gamble. He sold his first company in 2006 and then founded a data-driven company focused on politics and activism. He is now active as a hands-on angel investor in WordProof, and in human rights for international organizations.Julian Sanjivan, Project Manager: An Executive Board Member with New York City Pride, heading the annual NYC Pride March. Julian brings 15 years of experience to WordProof of managing the various facets of a successful organization including program development, strategic planning, human resources, finance, sales, and marketing.“What makes our team special is the extensive track record in both open-source as well as in communications and community.” — Sebastiaan van der LansWhat stage is Wordproof at and what are your plans for scaling?We have completed testing of the product with around 50 testers, and have presented the blockchain timestamp service project to 2500 developers at the biggest WordPress event in Europe, the WordCamp Europe conference.The WordProof Timestamp plugin is available now on WordPress.org and we are working on several big improvements to it. We are also developing solutions for non-WordPress websites and services so they can timestamp with WordProof as well. After talking with hundreds of publishers and other interested parties, we noticed that many did not want every editor to have a personal blockchain account and most parties thought managing a blockchain account and operating a wallet was still difficult.This is why we developed the We Stamp For You service, which automatically timestamps new content on the background using a special Timestamp-key.Besides that, we have decentralized WordPress hosting on the roadmap — as more than 70% of WordPress sites are vulnerable to common attacks, blockchain could make a big difference here.We are also actively looking to form partnerships with impactful companies around the world to empower the public and website owners with the tools to build and run a more reliable internet.Why did you decide to use blockchain technology, and specifically EOSIO?Blockchain technology is able to prove trust, which is a unique ability and something which will have a huge impact on online content management and publishing.EOSIO, like WordPress itself, is open source, which makes the ecosystem more collaborative and transparent. The fast block times (0.5 seconds) of EOSIO blockchains are crucial — the world of online content moves quickly, and 20 minutes is too long to wait for content to be protected.We also love that EOSIO blockchains do not charge fees to end-users. We believe that proving your integrity should be free, if it is to be scalable. The main focus of our products is accessibility, and the advantages of EOSIO blockchains mentioned make it the ideal blockchain software for us to build with to reach an internet-scale user base.An Example WordProof Timestamp CertificateHow has the EOSIO Community responded to your project?We were initially funded by a Telos Worker Proposal grant, which was the first one to successfully fund a new open-source initiative. We have been featured by community publications like Everything EOS and The EOS Writer.Interestingly, we have had interest from the WordPress community as well, being covered in a leading WordPress blog.In fact, the co-founder of WordPress, Matt Mullenweg, even said WordProof is “one of the coolest things” he has seen so far in the overlap between blockchain and WordPress!What industries stand to benefit most from using WordProof?While practically every industry which uses the internet can benefit from increased transparency and provenance of content, we see four industries which stand to gain the most from using WordProof technology:Legal and MedicalConsumers should be 100% sure that medical or legal advice online has not been tampered with, and that the issuer of the advice takes responsibility and can be held accountable for dispensing it.E-CommerceConsumers should know exactly what they agreed to (purchases, terms and conditions) and should be able to hold websites accountable if the agreement is breached.Public InstitutionsWhen governments and municipalities disseminate information to the public, the public should be able to trust this information and verify its authenticity.JournalismConsumers should be able to see who the creator of the content is, and what edits or adaptations have been made, and exactly when.Where do you see WordProof Trusted Timestamping in the future?Change online is inevitable at this point: trust is in decline and the public is losing faith in things that have let them down repeatedly.We believe blockchain timestamping should and will become a web standard, and WordProof is providing the foundations for this to happen. We want to see WordProof playing a vital role in active collaboration between the WordPress and EOSIO communities to build a safer and more reliable internet.More information on WordProof is available at: https://wordproof.ioBuilding on EOSIO?Our #BuiltOnEOSIO series showcases some of the amazing projects leveraging EOSIO technology to build a more secure and connected world. If you would like to suggest a project for us to feature please send an email to spotlight@block.one for our Developer Relations team to review.- Block.one Developer Relations teamImportant Note: 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.WordProof Puts Content Trusted Timestamping on EOSIO Blockchains was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Remme Releases a Distribute...

Can you introduce Remme to us?Remme is an ecosystem of identity and access management products with a digital key at its core. Developers can make use of Remme’s open source distributed PKI protocol, while their certificate management platform offers solutions for enterprise clientele. Remme was founded in 2015 with the goal of building a next-gen Public Key Infrastructure (PKI) protocol and suite of decentralized PKI-enabled apps to address the challenges of Web 3.0.That PKI protocol utilizes the EOSIO codebase to create a decentralized system for storing and revoking digital keys in a highly secure manner.Remme Protocol anchors the Remme ecosystem, including the blockchain layer to host identity information, tools on top of it that manage both machine and user identities, and finally the layer that enables custom apps for a variety of PKI use cases.As an example, we have already implemented several pilots that utilize Remme Protocol, one of which is a blockchain-based customer authentication project for a Fortune 500 automotive manufacturer.A hierarchical view of the Remme ecosystemWhy is PKI a good use case for blockchain technology?We are convinced that the PKI solution that was introduced in the 1970s is simply not capable of meeting the needs of the modern web, especially with such powerful new technologies emerging.Today, just as 40 years ago, certificate authorities (CA) are responsible for digitally signing and publishing public key certificates using the CA’s key. This presents a single, centralized point of attack. Compromise the CA, and the entire suite of keys they oversee is in jeopardy.The evolving needs of enterprises, their increased connectivity, and the enhanced capabilities of ever more sophisticated attackers have necessitated a transition to a more resilient alternative. That alternative resides on the blockchain, where many of the fundamental weaknesses of traditional PKI do not apply.What prompted you to fork EOSIO and operate your own blockchain network?EOSIO forms an excellent base on which to develop Remme Protocol. However, we made the decision to launch as an independent network because we wanted to be able to customize key components, such as configuring the consensus so that Block Producers themselves could serve as the network’s long-term stakeholders.We also wanted to simplify the resource economy by managing RAM, NET, and CPU simultaneously, powered by the REM token, so as to improve UX and eliminate much of the complexity from the perspective of end-users. Using our own fork of EOSIO also enables us to create bespoke PKI-related features out of the system smart contracts.We began by customizing the EOSIO codebase to accommodate our specific use cases and token economy. Since we have a large community of token holders and Block Producers, we had to explain to them the changes in detail. We detailed these changes in a series of educational blog posts and visualized the key modifications related to the features we inherited from EOSIO, namely its consensus, governance and resource economy.Why did you choose to use EOSIO blockchain technology?We actually started out using Hyperledger Sawtooth as our blockchain framework but encountered an array of problems that persisted throughout testing. As the date of the first testnet drew nearer, it was evident that Sawtooth wasn’t cut out to handle the sort of use cases we’d envisaged, and certainly not at scale.It was evident that we needed an alternative blockchain solution that was more flexible, customizable and capable of operating at scale to serve millions of connected devices. After exploring the alternatives, it became apparent that EOSIO was by far the best option for Remme.Which components of the EOSIO architecture, in particular, attracted you?The main factors that influenced our decision were DPOS consensus, and that the EOSIO resource management concept fit very well into our token economy, and the decentralized PKI concept.EOSIO has been extensively tested at a very high level and has significant industry recognition. It works on a global scale, supporting hundreds of commercial-scale dApps. Additionally, the EOSIO ecosystem has a tremendous developer community that expands the codebase and the independent surrounding tools towards every possible use case. The protocol’s ability to support commercial-scale dApps that are suitable for enterprises sealed it.How will the use of blockchain technology transform the current PKI system?Many of the characteristics for which blockchain technology is renowned are naturally suited to identity and access management. These include built-in transparency, censorship resistance, and widespread availability via a distributed network of nodes.Blockchain based systems also eliminate certain attack vectors including man in the middle (MITM) attacks. Because enterprises are interacting directly with the blockchain, without reliance on a central authority, stealing or compromising certificates becomes exponentially harder.Moreover, because the blockchain itself is supported by a broad array of entities, and overseen by a global system of validator nodes, businesses can rest assured that services will be maintained in perpetuity, without the risk of the Certificate Authority going out of business or cutting them off.What are some of the use cases that have been devised for Remme?Passwordless user authentication and smart device authentication are two of the most obvious applications, but the number of use cases is limitless; we intend to focus on introducing identity solutions at first such as digital key management, domain validation, and SSH key management. In the future, we envision Remme Protocol being used to control access for thousands of businesses, hundreds of thousands of users, and millions of IoT devices.Can you tell us a bit about your team and what makes them special?Remme’s core team has a wealth of blockchain and cybersecurity experience that stretches back almost a decade.Our, CTO Roman Cherednik, has extensive experience in blockchain and PKI project development, including a global software development company with $650M revenue with over 13,000 employees, as well as a stint at an established crypto exchange.Then there’s our Head of Business Development Sid Desai, who leads our US office. Thanks to a career at Certificate Authority GlobalSign, he’s been deeply involved with PKI and has seen the many ways in which it can be improved.With 30 additional seasoned tech and marketing experts, Remme is well placed to make good on its promise of spearheading the creation of next-gen PKI solutions.The Remme team in action at a conferenceWhy did you decide to make Remme Protocol open source and have you encountered any unique challenges or benefits as a result of this decision?For us, it is imperative that Remme Protocol is fully open source.This is expected of blockchain technology, the value proposition of which hinges partially upon a fully transparent and open framework, and without which mass trust and thus mass adoption would be impossible.The benefits of harnessing open source technology include being able to leverage advanced software such as EOSIO, which saves us from having to build everything from scratch and provides certain security and developmental assurances.In return, we hope that the open source applications we build upon EOSIO will be utilized and expanded upon by other developers. We have a very strong open source Remme community, including third-party devs who are solving an array of real-world challenges using our tech.What are the future plans for Remme protocol, and the company itself?We have huge plans in the pipeline! At Remme, we believe that the way the modern world handles digital identities doesn’t cut it anymore. The number of digital identities, both human and machine, continues to grow at an incredible pace. That’s why we’re determined to lead the transition towards secure and simplified identity management.In terms of Remme Protocol, we plan to launch the mainnet by the end of this year. In 2020, we’ll focus on addressing other next-gen PKI challenges such as decentralized domain validation and SSL/TLS, email security, code signing and browser integrations. And 2021 will be dedicated to the IoT universe.As for product development, we intend to further develop Remme Auth, which addresses human identity management, and we are actively developing our second flagship product, Keyhub, which is for machine identity management.Unlike Auth, which will begin its journey together with Remme Protocol from mainnet launch, Keyhub is already live and already solves the problems of today’s PKI world related to certificate lifecycle management. More than 100 enterprises are using Keyhub already.Remme presenting for GartnerCan you tell us about your future plans for using and modifying EOSIO for your purposes?Once we’ve finished tailoring the consensus and resource management layer, we intend to focus on developing system smart contracts to add account attribute management. This will enable attribute-based credentials and access control use cases. Then we will work on external state verification. This will facilitate consolidated on-chain resolutions about events that reside and occur outside the blockchain. As a result, on-chain smart contracts and the applications built on Remme Protocol can subscribe and react to the events that happen in the real world.After these two components, we will continue to deliver extra PKI-related features out of the system smart contracts required for other use cases such as email security and code signing.Building on EOSIO?Our #BuiltOnEOSIO series showcases some of the amazing projects leveraging EOSIO technology to build a more secure and connected world. If you would like to suggest a project for us to feature please send an email to spotlight@block.one for our Developer Relations team to review.- Block.one Developer Relations teamImportant Note: 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.Remme Releases a Distributed Public Key Infrastructure was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOSIO™ Strategic Vision: En...

An evolving marketplace demands new innovations. It means developers must produce robust, secure, reliable software. The EOSIO™ Strategic Vision hones in on four specific developmental areas that make up the foundation of the platform: Scalability, Developers, Users, and Enterprise. In this fourth and final entry of the Strategic Vision series, we will discuss the complex needs of EOSIO Enterprise Blockchain customers and how the EOSIO platform will evolve to meet them.The following topics of focus are detailed in pillar 4 of the EOSIO Strategic Vision:High-Performance Consensus AlgorithmsBusinesses need efficient processing solutions to keep services live, so in order for blockchain technology to meet the needs of enterprise businesses, it’s essential for blockchain software to scale. Consensus is at the core of many of the benefits of blockchain like immutability, validation, and security thus improving consensus solutions to increase speed to finality remains a priority for EOSIO blockchain performance. Our research continues to improve custom-tooled, fault tolerant, and highly-performant consensus algorithms that intermesh to meet enterprise grade needs.Tools for Regulatory ComplianceIn order for blockchain technology adoption to scale on an enterprise level, solutions must meet regulatory requirements across regions. Larger companies that operate internationally must comply with complex regulations and their technology solutions of choice must rise to meet those needs. Inherently, the immutability and transparency of any blockchain lends itself to audit and compliance. The ability to work within an ever evolving regulatory environment is a cornerstone of the flexibility of the EOSIO platform. With that in mind, we continue to explore ways to evolve the ways in which EOSIO can be implemented across both public and private use cases to align with various regulatory needs. This includes research into ways applications can store data on the blockchain that can be selectively removed as regulations require without compromising the integrity of the blockchain data.Token CreationTo better serve businesses wishing to create their own token, we’re creating simple interfaces that reduce technical barriers. This will make it possible to rapidly issue and manage a token without having to deploy a contract. There are a variety of ways tokens are being implemented beyond financial use cases in businesses, and as the utilities for tokens expand we are dedicated to lowering the technical barriers to developing new token standards on EOSIO to meet enterprise needs. Remember that even though token creation is possible as a technical matter, each token’s compliance with applicable laws and regulations must be assessed.Enterprise-Grade SecuritySecurity is a pillar upon which EOSIO has always focused and evolved as the software continues to grow. There are many aspects of security, some of which stem from implementing secure data storage practices to security standards like WebAuthn and even improved user experience. Our team is looking at integrating multi-signature authentication and enabling hardware keys for block producers, in addition to bolstering the infrastructure for key storage and permission systems. This will deliver enterprises a means to better protect the accounts by implementing more dynamic security measures.EOSIO Specification RepositoryThe community effort towards building stable, efficient, and scalable EOSIO blockchains remains ongoing and we will continue to provide support and resources. We are continuing to implement various facets of the EOSIO Strategic Vision and during this crucial stage the feedback we receive from researchers, application developers, and other members of the community makes an impact. This effort is spearheaded by the Specification Repository, an EOSIO Labs™ initiative to support greater synergy amongst stakeholders in our growing ecosystem. If interested in getting involved, please review the specifications drafted and provide feedback directly in GitHub as we work through the implementation of these features in EOSIO.Continue reading about the additional pillars of the Strategic Vision below:Scalability — More apps, more usersDevelopers — Better tooling, faster app developmentUsers — Greater security, less frictionStay ConnectedThe EOSIO blockchain platform has been designed from the ground up to scale and meet the needs of enterprise entities. We will continue to iterate beneficial changes as we receive feedback from the participants who make use of our technology and provide us input. If you would like to offer feedback and work more closely with our team to improve EOSIO for developers, you can send our developer relations team an email at developers@block.one.We continuously update our mailing list with future announcements and release notes. Subscribe today on the new EOSIO website.Important Note: 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.EOSIO™ Strategic Vision: Enterprise Blockchain (Part 4 of 4) was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOSIO™ Alpha Release: Andro...

Block.one is committed to supporting a wider range of security solutions for applications built on EOSIO. Sensitive data requires secure methods for storage and retrieval, and for a thriving blockchain application ecosystem, safeguarding private keys is essential. Our latest software release is geared towards seeking to address security for private keys on Android devices.We previously released software development kits (SDKs) for Swift and Java that support the rapid development of EOSIO blockchain applications on mobile platforms. This alpha release of our Android Keystore Signature Provider builds upon our EOSIO SDK for Java, allowing developers to engineer a hardware-backed keystore into mobile applications on Android operating systems. If a hardware option is unavailable, the keys will default down to a secure software container environment.Tools that Improve Private Key ManagementIn the past, we introduced the concept of signature providers as a guide for the development community at large to adopt better security practices for private keys. These plugins demonstrate how it is possible to limit vulnerabilities by signing transactions without exposing private keys. Ultimately, with the right implementation and tooling, developers can improve the experience of users by avoiding unnecessary handling of private keys.The Android Keystore plugin allows developers to store cryptographic keys in a secure container on the device making them more difficult to extract. Once keys are in the Keystore, they can be used to sign transactions without exposing them to external applications.The intention is that no-one can see the private key except the secured hardware, not even the user, once the keys are stored inside an Android device that supports the hardware-backed keystore. This hardware solution should offer superior security as opposed to alternatives like computer backups, password managers, or even a piece of paper.This plugin for Android Keystore is similar to the support we released in the past for Apple’s Secure Enclave, in that it allows developers to store private keys on the device and the plugin manages keys and transaction signing. This measure, coupled with in-device biometric authentication, provides a simple, more secure option for private key management.Providing a more streamlined method for users to sign transactions without exposing their private keys will improve user experience and security, helping to accelerate the adoption of blockchain applications. Follow the instructions in the Android Keystore Signature Provider plugin repository to learn how to extract and convert public keys from Android Keystore using the EOSIO SDK for Java library.Stay ConnectedIn order to better serve a growing community of EOSIO blockchain developers, Block.one is committed to creating an open forum for community feedback. If you would like to offer input and work more closely with our team to improve EOSIO for developers, you can send our developer relations team an email at developers@block.one.Join our EOSIO mailing list to stay up to date on the latest news, events, and releases for EOSIO.Important Note: 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.EOSIO™ Alpha Release: Android Keystore Plugin for the EOSIO SDK for Java was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOS Studio Streamlines Bloc...

Phil Li, CEO of Obsidian Labs, tells us about EOS Studio, a Cross-Platform Integrated Development Environment (IDE). EOS Studio is their end-to-end solution that aims to be the standard tool for app development on EOSIO.Could you introduce EOS Studio to us?Phil Li: EOS Studio is a cross-platform IDE for blockchain application development on EOSIO.By integrating numerous tools required in EOSIO into a graphical interface, EOS Studio can help developers improve their efficiency substantially throughout the entire app development process. It can also help people who are new to EOSIO get started with app development easily.In just three months after our release, we attracted thousands of developers and received very positive feedback. Many blockchain application development teams in the community have already used EOS Studio as their standard tool for developing apps. We hope EOS Studio can help to incubate more quality blockchain applications on EOSIO in the future.Why did you decide to create a Cross-Platform IDE?Phil Li: When developing EOSIO apps, many developers face the problem of having to learn different tools, manage them separately, and operate them on the command line. Our initial idea was to build an IDE to bring those EOSIO-related tools together in a graphical interface as a single application. We think this would significantly help EOSIO developers when they are working with complex codes or smart contracts. We spent a few weeks to implement this idea as a proof of concept, tested it in a small EOSIO developer group, and received very positive comments and support. This encouraged us to keep improving EOS Studio.How does EOS Studio help developers?Phil Li: EOS Studio provides a powerful and easy-to-use environment for app development. We designed it to be a platform that covers the entire app development process. It is not only a code editor. Developers can build and deploy smart contracts, manage the local environment, debug and test their contracts, and manage private keys, all in EOS Studio. Unlike other smart contract software developer tools, EOS Studio allows developers to build a project from end to end in a single application. And of course, building it on EOSIO means that we are using the best public chain for commercial apps.The EOS Studio team left to right: Xin Sun, Zehao (Phil) Li, Rose RenWho is working on the EOS Studio project?Phil Li: EOS Studio is a product of Obsidian Labs, a Silicon Valley-based startup focused on blockchain technology. Our founders were Y Combinator alumni and have been working together on blockchain for more than two years. We won the 3rd place of the EOS Global Hackathon in San Francisco.I’m a full stack developer with experience in mobile and web applications, blockchain and smart contracts. The other two founders Rose Ren and Sam Sun are veterans at managing blockchain communities, organizing developer meetups and conferences, and in business development with other communities and the top block producers of EOSIO. They are responsible for community and marketing in the US and Asia, respectively.What has the response of users/the community been?Phil Li: The EOSIO community is very excited about EOS Studio. In the past three months, our product has attracted thousands of developers worldwide and they use EOS Studio for everything from learning the technology of EOSIO to building complete apps on the EOS public network. Some supporters also produced introductory YouTube videos or wrote Medium articles about EOS Studio. Our Telegram group is very active and we received a lot of encouraging messages. Many developers are looking forward to our new features.What are the future plans for EOS Studio? Are you working on any particular new features?Phil Li: We have just released the web version of EOS Studio, which will allow anyone to start a blockchain project within seconds. The entire IDE will be in-browser, with cloud-based EOSIO smart contract compilation and blockchain network connections — this will significantly lower the barrier of entry for EOSIO development and attract more developers into the ecosystem. It is also a platform to share open sourced smart contracts (like GitHub) so that developers can learn from each other. We have received a lot of ideas from the community so we will continue to iterate the product to provide more useful features for EOSIO developers in the future.The web version of EOS Studio is live now: https://www.eosstudio.io/webMore information on EOS Studio available at https://www.eosstudio.io/Stay ConnectedAs the global EOSIO developer ecosystem grows, there has been a corresponding increase in the number of projects focused on development tools and infrastructure. These programs, libraries and utilities can help developers save time, effort and resources which results in more and better applications being built for EOSIO users. The Developer Relations team is committed to making EOSIO the blockchain platform with the best and most accessible developer experience, and highlighting #EOSIOTools which are useful to developers is part of our strategy to nurture and cultivate the developer ecosystem.Stay tuned to our #EOSIOTools series where we’ll highlight some of the most useful software and tooling being built by the community for developers building on EOSIO.If you have a tool you’d like to share with us, please email spotlight@block.one.-Developer Relations teamImportant Note: 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 Studio Streamlines Blockchain App Development with their Cross-Platform IDE was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOSIO™ Strategic Vision: Bl...

Improving the EOSIO™ software suite is an ongoing endeavor and requires a holistic approach given the diverse roles of system-wide participants. The EOSIO Strategic Vision outlines four major points of focus: Scalability, Developers, Users, and Enterprise. This entry in the Strategic Vision series addresses blockchain users and improvements we are making to the EOSIO software suite to support them.Reducing friction for users of blockchain applications will go a long way towards supporting mass adoption. Users need access to secure, simple, and familiar interfaces in order to confidently use blockchain systems. Towards that effort, strides have been made by our team to develop and propose security standards for interactions between authenticators and applications built on EOSIO based blockchains like advances recently released in the Ricardian Template Toolkit.The following topics of focus are detailed in pillar 3 of the EOSIO Strategic Vision:A Consistent Front EndPhishing, bait and switch, and other types of attacks use false pretenses to trick users into making otherwise unacceptable agreements, without revealing the true nature of what users are agreeing to. To stifle these malicious efforts our team is continually advancing support for Ricardian Contracts and a toolkit for validating onchain image rendering, text, and attachments, that clearly indicates the terms a user is agreeing to when they sign a transaction. By giving developers templates to put clear terms and conditions alongside transaction signing, it makes it easy for users to know exactly what they are agreeing to. These added transparency measures will provide users security and confidence as they navigate straight-forward interfaces.Enabling WebAuthn SupportPrivate key and password management can be worrisome and present major attack vectors if sensitive data is stored on an insecure system. Hardware authenticators are a step towards siloing passwords and/or private keys from harm’s way. WebAuthn is a new World Wide Web Consortium (W3C) standard providing secure authentication support for all leading browsers and platforms pioneered by major technology companies including Yubico, Google, and Microsoft. Adopting the WebAuthn standard because it makes it possible to incorporate hardware devices into existing authenticator architectures. These include the newly released EOSIO supported YubiKey, built-in authenticators such as fingerprint sensors, and other biometric confirmation tools.Enhanced Resource ManagementAt present, users are required to own or lease sufficient tokens to cover CPU and NET resources needed to execute transactions. New functionality allows developers to have a greater degree of autonomy over how billing for CPU and Network usage is processed. The proposal for this tool is outlined in the Specification Repository. Once enabled, the EOSIO blockchain will only charge the first authorizer of a transaction for related CPU and Network costs. This allows application developers to set a criteria for specific transactions and cover any associated user costs. By covering customer fees, developers can help to alleviate any adoption barriers related to transaction cost.Decentralized File SystemToday application business logic is encapsulated as smart contracts and associated data is stored on the blockchain. However, application user interfaces are still built and hosted off-chain, representing single points of failure for decentralized applications and a capacity for censorship. We are exploring ways of enabling on-chain storage of the application user interfaces, perhaps in a separate lower cost resource that can enable applications to finally become truly decentralized and therefore effectively censorship resistant as well.EOSIO Specification RepositoryThe community effort towards building stable, efficient, and scalable EOSIO blockchains remains ongoing and we will continue to provide support and resources. We are continuing to implement various facets of the EOSIO Strategic Vision and during this crucial stage the feedback we receive from researchers, application developers, and other members of the community makes an impact. This effort is spearheaded by the Specification Repository, an EOSIO Labs™ initiative to support greater synergy amongst stakeholders in our growing ecosystem. If interested in getting involved, please review the specifications drafted and provide feedback directly in GitHub as we work through the implementation of these features in EOSIO.Stay ConnectedUsers are among the most vital participants of the EOSIO blockchain ecosystem, and Block.one is committed to incorporating community suggestions and feedback. User input helps to inform and improve our open source toolkits, ultimately creating a more robust, secure, and engaging experience for everyone. If you would like to offer feedback and work more closely with our team to improve EOSIO for developers, you can send our developer relations team an email at developers@block.one.Get updates on future announcements and release notes by subscribing to our mailing list today on the new EOSIO website.Important Note: 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.EOSIO™ Strategic Vision: Blockchain Users (Part 3 of 4) was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOSIO™ Strategic Vision: To...

While the EOSIO™ software ecosystem continues to grow, improving the developer experience building on EOSIO is at the forefront of our minds. In the EOSIO Strategic Vision, we identified four central points of focus for a collective approach to platform development; Scalability, Developers, Users, and Enterprises. This article focuses on enhancements for Developers and the tools that help them build.To ease friction with software deployment our goal is to make the best tools available for developers building on EOSIO. Blockchain system architects need a means to inspect blocks and transactions, streamline compatibility for multiple authenticators, and ways to reliably audit and debug smart contracts. They need test environments and robust documentation to aid in deployment and on-boarding new talent to their organizations. In addition, overall improvements to smart contract searchability and functionality will expand the capabilities of EOSIO blockchain applications.A smoother experience for developers means a clearer path to building a more robust and diverse blockchain ecosystem that provides users secure applications to fit their needs. Developers make this diverse ecosystem possible, and to help them deliver we are dedicated to improving their experience on EOSIO. Below are the initiatives we have outlined in the EOSIO Strategic Vision to move EOSIO closer to that goal.The following topics of focus are detailed in the second pillar of the EOSIO Strategic Vision:Graphical User InterfacesFormerly, developers have been relegated to accessing nodeos (the EOSIO blockchain process) via a functional, albeit manual, command line interface. To improve this experience, we’re working on graphical user interfaces (GUIs) that can be utilized to launch nodeos, access block explorers for transaction and block inspection as well as other general development uses. We believe that offering tools with easily accessible user interfaces will provide greater flexibility and improve efficiency by allowing multiple developers to work in parallel on a single instance of nodeos. Our recent release of the EOSIO Explorer adds more visual tools into the EOSIO developer experience.Advancing the Universal Authenticator LibraryAnnounced earlier this year under EOSIO Labs™, Universal Authenticator Library ( UAL) provides a single integration and associated front end components for developers to build into their applications to support a number of compatible authenticators. This simple, unified approach not only reduces development time when compared to integrating with each specific authenticator a developer wants to have available in their application, it provides a more seamless and consistent user experience to end users of EOSIO based applications improving usability across the growing ecosystem of blockchain applications. UAL makes it possible for developers to provide a unified front end experience in their application giving users the option to choose an authenticator that best suits their needs or personal preferences. The future of the UAL library will see a wider range of authenticator support as it is adopted across the ecosystem.EOSIO SDKs for Java and SwiftTo better serve a user base across multiple mediums EOSIO blockchain application developers often take web applications and replicate them for the sake of mobile device interface. Developers can use both the recently released Java and Swift libraries to generate applications in native Android or iOS platforms, providing faster response time, and more finely tuned interfaces on the user end. As we receive feedback and continue to fine tune these SDKs, we will continue to release additional improvements.Debugging Smart ContractsExploration continues to better deliver superior smart contract debugging resources. Promising research is underway on tools that let developers add breakpoints to their smart contract code so that functions can be reviewed in a step-through process during state exploration and auditing. More robust tools available for smart contract development will help developers build more seamless and secure contracts on EOSIO.The EOSIO TestnetAs options for testing the deployment of smart contracts are limited, our team is working on a testing infrastructure that is integrated with our developer documentation and can guide the user through the process of testing on a testnet. Providing additional documentation as a guide will better onboard new developers to the EOSIO platform and make it easier for existing developers to run testing cycles before deploying their applications into production environments.Scalable Documentation PlatformWhile continuous updates are made at a rapid pace to improve many facets of the EOSIO source code, we are working in parallel to streamline our developer portal to provide a more seamless experience in sync with the scale of the EOSIO software codebase. Additionally, to maximize inclusivity in a global development environment we’re exploring multi-lingual support for core updates to documentation to provide a greater degree of support to non-english speaking developers in the ecosystem.High Resolution State TrackingIn the past, developers tracked state differences on a per-block basis with official tools such as the State History Plugin. Going beyond blocks, we’re continuing to investigate how to give developers more control over behavioral review of smart contract state changes. This would make it possible to refine the scope of review to individual transactions or actions, offering developers greater flexibility with the implementation of data aggregator tools. Developers will be able to gather these data points for applications outside smart contracts and avoid associated logic errors. Tools that enhance data access, like the State History Plugin, provide efficient real-time access to on-chain data while architecture patterns such as Demux allow developers to offload storage and queries to a scalable database like MongoDB.Enhanced Smart Contract FunctionalitySmart contracts need to be able to refer to one another and update their state data without causing clashes. When one smart contract accesses another smart contract’s state data it does so by referring to a corresponding table. When the accessing smart contract refers to another’s table, it incorporates that table’s structure into its code. If the smart contract whose data is being referred to ever makes a change to that table it will create a conflict. To remove this limitation we are testing the viability of enabling smart contracts to use a read-only layer to which other smart contracts can refer so each can update their data structures without any errors.EOSIO Specification RepositoryThe community effort towards building stable, efficient, and scalable EOSIO blockchains remains ongoing and we will continue to provide support and resources. We are continuing to implement various facets of the EOSIO Strategic Vision and during this crucial stage the feedback we receive from researchers, application developers, and other members of the community makes an impact. This effort is spearheaded by the Specification Repository, an EOSIO Labs™ initiative to support greater synergy amongst stakeholders in our growing ecosystem. If interested in getting involved, please review the specifications drafted and provide feedback directly in GitHub as we work through the implementation of these features in EOSIO.Stay ConnectedThe EOSIO platform is expanding both in scope and technology, driven in part by community input. That feedback leads to improvements in previous software releases and assists with forthcoming innovations. While we continue to invent and integrate new solutions we intend to work hand in hand with the community towards a bright future. If you would like to offer feedback and work more closely with our team to improve EOSIO for developers, you can send our developer relations team an email at developers@block.one.We are continuously updating our mailing list with future announcements and release notes. Subscribe today on the new EOSIO website.Important Note: 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.EOSIO™ Strategic Vision: Tooling EOSIO for Developers (Part 2 of 4) was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

GeneOS Taps Blockchain to U...

Albert Chen, co-founder and CEO of GeneOS, explains how his company combines personal wellness insights with the potential of individuals being able to share in the value from their genetic data.How would you describe your project?Albert Chen: GeneOS is a self-sovereign personal genomics and wellness platform where users can obtain health insights generated by an algorithmic agglomeration of their DNA, lab and activity data. The data storage and access are powered by cryptography and privacy-preserving technologies, allowing users to share in the value created by their data without losing ownership. The underlying protocol G.E.M., which stands for the Genome Equity Model, tokenizes each data collection. Eventually, participants may be able to benefit from renting their data for research or getting paid for personalized healthcare recommendations.Illustration of the Genome Equity Model (G.E.M.) ProtocolWhere did your initial idea come from?Albert Chen: Since (Chief Product Officer) Jay Bowles and I had developed an application using non-fungible tokens in the summer of 2018, we were inspired to create a decentralized marketplace for digital assets going into the London Hackathon. It soon became apparent that one of the most interesting use cases for digital assets would be data access. Jay, with his degree in genetics and his familiarity with the personal health data space, guided the team into eventually finding this niche where data proliferation is not only critical for social impact but would also be best facilitated by blockchain technology.Can you introduce your team and tell us what makes it special?Albert Chen: Our team is comprised of two pairs of ex-co-founders: Jay and Jens Elstner (CTO), whose personal health data analytics platform Keepzer pushed the self-sovereign-data narrative in 2013. There’s Ben Tse (Chief Creative Officer) and me, whose e-commerce houseware brand UM launched in 2011. This leads to a very balanced mix of expertise in our team. Ben creates the brand identity, visual design and user interface, Jay translates them into front-end user experience and devises the product incentives, Jens constructs the supporting back-end technical infrastructure and logic. I connect them to the blockchain and circle back to Ben with digital marketing and business strategy.The GeneOS team (left to right): Benjamin Tse, Jens Elstner, Albert Chen, Jay BowlesWhat stage is the project at and what are your plans for scaling up?Albert Chen: Our core offerings consist of two products: the G.E.M. protocol, on which the genetic data profit-sharing is made possible, and the GeneOS platform, which is a personal wellness dashboard that offers insights and analytics based on genomic and other health data. We are currently doing internal testing on our protocol and have just finished designing the wellness platform, which we plan to scale by targeting early adopters with interest in genomics-aided wellness insights. The platform will feature a more intuitive and informative dashboard, which will be critical in gaining initial adoption.Why did you decide to use blockchain technology, and specifically EOSIO?Albert Chen: Blockchain technology marks the first time that it is possible to have tamper-proof and censorship-resistant records of who owns what. This is the only way self-sovereign data monetization can work without any intermediary. However, most blockchain implementations offer cumbersome user experiences. We believe adoption for consumer-facing products such as GeneOS can only be accomplished with a blockchain-invisible approach. EOSIO’s account architecture, fee-less transactions, and WebAuthn integration allow us to create a blockchain application with the experience of a standard app. Moreover, the choice of C++ as the smart contract language and the available development toolkits make it very easy to develop and iterate on EOSIO.The GeneOS PlatformHow has the EOS Community responded to your project?Albert Chen: We’re very grateful to have received mostly positive feedback from the community, with many people telling us that they had been holding off on sequencing their genome until we came along. We also received a fair bit of product launch subscriptions after winning the EOS Global Hackathon Series Grand Finale.More information on GeneOS available on https://www.geneos.me/Building on EOSIO?Our #BuiltOnEOSIO series showcases some of the amazing projects leveraging EOSIO technology to build a more secure and connected world. If you would like to suggest a project for us to feature please send an email to spotlight@block.one for our Developer Relations team to review.Block.one Developer Relations teamImportant: 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.GeneOS Taps Blockchain to Unlock Health Data Insights and Incentives was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOSIO™ Alpha Release: Histo...

As blockchains grow with each authenticated transaction, querying and reading history and state data proves to be a growing challenge. In order to tackle this challenge, we have been working on a series of History Tools designed to make data more accessible for EOSIO based blockchains. You can find more technical details and documentation in the History Tools repository on GitHub. Documentation for History Tools can be found here.We have previously released the State History Plugin that makes accessing blockchain data easier. The state history plugin saves blockchain state data to a new flat-file format and exposes a websocket interface to read the block/state data. With the alpha release of the History-Tools solution, we take this one step further and introduce database fillers to read the state data and populate PostgreSQL and LMDB databases that can be queried with the specialized client and server WASMs.Rich user experiences and reliable applications built on EOSIO require tools that allow applications to efficiently access and query data from the blockchain and smart contracts. By nature, blockchain systems store data in a sequential manner that doesn’t easily lend itself to scalable random access query and retrieval systems.As this is an alpha release, we expect to iterate changes throughout the development process. It is our hope that feedback from members of the community will help to provide us additional guidance as we roll out these tools.WASM-Query LanguageWASM-Query Language (WASM-QL) implements a client-server architecture to design and execute queries in WASM. This implementation pattern allows contract authors to design and code queries using the same tooling used to create contracts and leverage the client-server query architecture. It also minimizes the back-and-forth communication required between client and server optimizing speed and efficiency. Once enabled, this system would make it possible to inspect historical states at any given block height. In addition, since replication in this system is relegated away from nodeos towards low memory-intensive query processes, it is more conducive to scalability.This offers a more streamlined approach for the general-purpose query engines that enable applications to gather data from the EOSIO smart contracts. In addition, authors of contracts and applications can design their own queries with the same toolset that contracts are designed with, providing overall greater synergy.There are two types of queries that wasm-ql-pg supports:Binary queries are the most flexible. A client-side WASM packs the query into a binary format, a server-side WASM running in WASM-QL executes the query then produces a result in binary format, then the client-side WASM converts the binary to JSON. The toolset helps authors create both WASMs.An emulation of the /v1/ RPC API.In time, we may choose to drop the client-side WASMs and switch the format of the first type of query to JSON RPC, Graph QL, or another format. We appreciate community feedback as we make these decisions, so please comment in the repository with the recommendation you support.Fill-pgFill-pg is designed to offer applications a lightweight solution to gather all pertinent data they would normally receive from monitoring the main chain. The information gathered includes:Header information from each blockTransaction and action traces, including inline actions and deferred transactionsContract table history, at the block levelTables which track the history of chain state, includingAccounts, including permissions and linkauthsAccount resource limits and usageContract codeContract ABIsConsensus parametersActivated consensus upgradesFill-pg cuts dead weight by excluding blocks from the equation since they don’t include the inline actions and deferred transaction data that applications need. It supports both full and partial history so users can decide if they want to query the entire chain or a subsection.Fill-lmdb, wasm-ql-lmdbThis pair operates identically to fill-pg and wasm-pg, however, data is stored using lmdb as opposed to postgresql; as an embedded database lmdb might provide administration advantages.Making Blockchain Data AccessibleIn order to deliver seamless user experiences for more complex applications that maintain the integrity of blockchain data, developers need robust access to deterministic databases that can be queried like their non-blockchain counterparts. Blockchain nodes have a narrow scope of query options which causes problems to arise when complex applications try to store and retrieve indexed data. Traditionally, this left developers with two options; either processing the data within the application or storing sorted data on the blockchain itself which can be inefficient and expensive.By reducing the back-and-forth between application databases and the EOSIO blockchain we’re following through on providing superior tools for Data Access Scalability, outlined in the EOSIO Strategic Vision. As we continue to receive feedback, we’ll continue to optimize methods that can reduce resource loads and help developers create more efficient application architectures.Stay ConnectedWe appreciate the efforts of those who continue to help test and provide input on these tools as they evolve to best serve the EOSIO community. If you would like to offer feedback and work more closely with our team to improve EOSIO for developers, you can send our developer relations team an email at developers@block.one.Remember, 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.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.EOSIO™ Alpha Release: History Tools was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOSIO™ Strategic Vision: Sc...

As the EOSIO™ platform continues to evolve, Block.one’s collaboration with the open source community building on EOSIO has become a critical component of the software’s adoption. Recently announced in the EOSIO Strategic Vision, we’ve proposed a foundation based on four core principles of focus: Scalability, Developers, Users, and Enterprises, each with fundamental features which set EOSIO apart. In this first article of a four part series to review each pillar of the Strategic Vision, we’ll take a closer look at Scalability and how we’re taking strides to maximize efficiency across EOSIO based blockchains.When it comes to mass consumer adoption of blockchain applications, scalability remains one of the greatest focal points. Through continuous research and innovation, our team has strived to develop a robust, efficient, and highly capable software environment that can rapidly scale to meet needs determined by marketplace dynamics. In fact, Bart Wyatt, our Director of Blockchain Development, recently published a byline focused on Blockchain Scalability on Cointelegraph that discusses various interpretations of scalability and why scale is the most critical component of blockchain’s adoption.Block Production: Vertical ScalingWASMRunning parallel instances of smart contract business logic isn’t always possible. This factor makes it important to maximize the single threaded performance of executing WASM code in smart contracts. EOSIO has been engineered with this tenet in mind, and delivers stellar smart contract performance by leveraging a wide range of WASM engines including WABT, WAVM, and our most recent announcement of EOS VM, a blockchain specific WASM interpreter with associated JIT compilers that further accelerate WASM performance. We are continuing to explore solutions for WASM engines that can rise to the challenge of blockchain technology related needs. Read more about EOS VM in our recent developer preview release announcement.Multi-ThreadingAs far as business logic is concerned, smart contracts are usually single threaded, so they generally process one command at a time. By identifying opportunities in dataflows for risk free concurrent processing our team is exploring the use of multiple cores to accelerate processing speeds without forcing developers to change builds.Improvements In NodeosOur team observed opportunities to build greater execution efficiency into the platform such as our recently announced EOSVM, a blockchain specific WASM engine, database access, intrinsics handling, and various other EOSIO platform and various other components. In order to maximize the scaling potential of nodeos, the team will be continually profiling each system in order to make the most of our ongoing optimization efforts.Advanced Database TechnologiesThe database supporting the current iteration of nodeos has been fine tuned to augment throughput and simultaneously offer the ability to rollback deltas on demand. Future efforts will stay focused on optimizing and integrating similarly performant database solutions capable of concurrently managing multiple non-conflicting transactions and that enable developers greater data indexing flexibility.Reducing Resource RelianceManaging finite resources has been a consistent obstacle for blockchain developers with sights set upon mass adoption. Scaling usage of blockchain networks to the performance of traditional systems will require more efficient use of resources like CPU, RAM, and Bandwidth a network will be able to provide. Our team has been hard at work probing possibilities, like resource exchanges and software side solutions, that can reduce the resource load and enable shared resources for companies operating blockchain applications.Block Production: Horizontal ScalingInter-Blockchain Communication MechanismsInteroperability across blockchains remains a core facet of the EOSIO Blockchain. By improving the communication across multiple blockchains with a formalized Inter-Blockchain Communication (IBC) protocol, higher transaction throughput rates can be achieved. Our teams are working towards implementing inter-chain mechanisms that provide applications enhanced scalability capacities. One of the methods we are exploring involves scaling by diversifying components across multiple chains that communicate together via a formalized IBC. Another scaling strategy we are considering involves replicating an application across multiple chains to manage user-request overflow. Yet another option we are looking into would be to enable two or more applications across blockchains to intercommunicate in order to handle process loads. We will continue to research and identify other opportunities where cross-chain compatibility enables greater throughput.Parallel Smart-Contract ExecutionSingle threaded smart contracts require a constantly maintained global state which can lead to execution constraints and intensive resource utilization to execute contracts. To overcome this state maintenance related drawback, we are exploring advanced memory management techniques that will expand multithreading support to encompass transaction processing, without superfluous cross-chain communication. We believe it is possible to extend such techniques to scale across node assemblies running multi-threaded processes.Abstraction LayersIn order to provide seamless front-end experiences cross-chain, we are also examining the possibilities for developers to create applications with greater ease that are able to interact with multiple blockchains. Rather than requiring application developers to juggle a series integrations, we’re researching how application developer level abstractions can simplify the back-end integration of such applications.Data Access ScalabilityAs the blockchain grows with each authenticated transaction, querying and reading history and state data proves to be a growing challenge. In order to tackle this challenge, we are working on a series of History Tools. WASM-QL implements a client-server architecture to design and execute queries in WASM. This implementation pattern allows contract authors to design and code queries using the same tooling they used to create their contracts and further the client-server architecture also minimizes the back-and-forth required between client and server. Once enabled, this system would make it possible to inspect historical states at any given block height. In addition, since replication in this system is relegated away from nodeos, towards low memory-intensive query processes, it is more conducive to scalability.EOSIO Specification RepositoryThe community effort towards building stable, efficient, and scalable EOSIO blockchains remains ongoing and we will continue to provide support and resources. We are continuing to implement various facets of the EOSIO Strategic Vision and during this crucial stage the feedback we receive from researchers, application developers, and other members of the community makes an impact. This effort is spearheaded by the Specification Repository, an EOSIO Labs TMinitiative to support greater synergy amongst stakeholders in our growing ecosystem. If interested in getting involved, please review the specifications drafted and provide feedback directly in GitHub as we work through the implementation of these features in EOSIO.Stay ConnectedAs always, Block.one’s commitment to incorporate community feedback into EOSIO remains unwavering. The input from each ecosystem participant provides us valuable insights that essentially inform the growth and help set the pace of advancement for the EOSIO platform. If you would like to offer feedback and work more closely with our team to improve EOSIO for developers, you can send our developer relations team an email at developers@block.one.Remember, 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.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.EOSIO™ Strategic Vision: Scaling the EOSIO Platform (Part 1 of 4) was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOSIO Labs™ Release: Specif...

EOSIO Labs™ Release: Specification Repository for Architecture and Approach Feedback — EOSIOAt the #B1June event, we announced the EOSIO Strategic Vision which outlines four foundational pillars where Block.one hopes to advance the EOSIO™ software: Scalability, Developers, Users, and Enterprise. As the ongoing evolution of EOSIO fundamentally relies on engagement with the developer community, we’re releasing a new repository to support greater synergy between every stakeholder in the ecosystem.The EOSIO Specification Repository, an EOSIO Labs™ initiative, provides technical design details for many of the ideas discussed in the Strategic Vision. It creates a dedicated repository in GitHub through which we can more closely collaborate with the developer community.Fostering Open Source CollaborationEOSIO is designed to foster an open source environment that will enable a more inclusive approach to the development process. The release of the EOSIO Specification Repository is an opportunity for everyone to review, comment, and build upon the ideas for which we’ve laid the foundation.The repository contains details regarding our current thinking on technical design choices and high level approaches one could take to realize the features and functionality outlined in the Strategic Vision. Further, the specifications are being released under the MIT License to encourage open collaboration.Specifically, we are sharing these specifications to:Seek feedback and have an open dialogue with others in the community on our approach.Encourage others in the community to build on and participate in the implementation of the ideas to further accelerate the pace of innovation in the EOSIO ecosystem.The following specifications are included in this initial release, intended for feedback and collaboration with the EOSIO Developer community:Forwarding Authorizations Between Contracts — Contracts can attest user authentication to other contracts. This enables contract-defined “subaccounts” that can use other contracts.Contract-Defined Transaction Authentication — Contract defined subaccounts can authenticate transactions between subaccounts. This makes lightweight accounts more useful, enables more-flexible account structures, and helps accounts from other chains interact with EOSIO-based chains.Contracts Paying Transaction Costs — Contracts can pay transaction costs (NET and CPU). Users with little or no resources would be able to use applications without requiring those applications to cosign the original transaction.Deprecate Deferred Transactions — We are exploring deprecating deferred transactions in nodeos for a number of reasons, including to simplify transaction processing and make it less error prone, fix complications with history and security issues. This recommendation explains some of the motivation behind this, and presents some potential replacements for existing use cases.Enhanced Token — This potential definition of a new token standard includes several enhancements. The increased functionality of enhanced tokens will allow them to support subaccounts allowing for cross-chain interactions. A new memo field allows users to send structured ABI defined binary data to contracts. A revamped notification system plays nice with Block Explorers, and we’ve phased out reliance on table structures resulting in more developmental flexibility for custom token contracts.Flexible Notifications — This notification protocol is being designed to be more flexible than previous implementations. It supports both contract-to-contract signals and contract-to-outside events.Get Current Producer — Provides the ability for smart contracts to identify the current block producer. This allows contracts the ability to identify discrepancies that are seen only with certain block producers, for instance.Key-Value Store — Potential database enhancements in nodeos implemented as a key value store that would provide increased flexibility, performance, and ultimately allow developers to write code that is robust against changing schemas.Query Resource Consumption — Smart contracts that are capable of paying transaction costs need access to certain data. By allowing smart contracts to access transaction NET, CPU costs, and their own RAM consumption it’s possible for them to use those metrics to accurately bill users.Contract Access to Subjective Data — In the same vein of accessing information, this proposal offers parameters through which subjective data including CPU costs, wall clock time, and a random number generator can be provided to smart contracts.Named Regions — Transaction throughput faces an eventual limiting factor relative to the smart contract serial execution model. Here we discuss an approach to scaling via parallel execution called “named regions”. Named regions could share a common block log which enables them to stay synchronized and help increase throughput.ABI 1.2: Sized Data in ABIs — This proposal gives ABIs a way to describe the content of sized storage, and to specify arbitrary fixed sizes.Synchronous Calls — Contracts rely on tables to communicate with one another, which means that when a table format changes it can create a conflict with other contracts. This proposal provides a method through which contracts can use read-only queries to synchronously call into each other.Tagged Data — Contracts may tag serialized data with custom types to identify it for decoding.Get InvolvedGet involved by submitting issues and join the discussion directly in the EOSIO Specification Repository on GitHub. Additional recommendations for contributing and how this repository will be organized are included in the Contribution Guide. We will be actively working to address issues there and stay involved in the discussion.Important ConsiderationsSince many of the specifications can be best described as forward looking projections about how one might implement the feature/functionality needs, we are unable to make any guarantees about eventually implementing the functionality as designed or being able to keep the specifications updated to match the eventual implementation. However, we encourage interested members of the community to engage with our engineering team and discuss the design choices we have outlined by filing GitHub issues against individual specifications. Please do note that we may not be able to respond to every element of feedback, or synthesize all the feedback into a consensus approach.Stay ConnectedWe want to hear from you, so if 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.Remember, 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.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.EOSIO Labs™ Release: Specification Repository for Architecture and Approach Feedback — EOSIO was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

EOSIO™ Version 1.8.0: Stabl...

EOSIO™ Version 1.8.0: Stable Release of Consensus Protocol Upgrade Features — EOSIOAs a contributor to the continued development and enhancement of the EOSIO™ software, we are pleased to announce a new stable release available for EOSIO. You can find more details about EOSIO v1.8.0 in the GitHub repository. Documentation on the EOSIO Developer Portal has been updated to reflect this release.This release marks major enhancements for EOSIO paving the way for a more secure and scalable future for EOSIO based blockchains. A number of consensus protocol upgrade features have been introduced which require changes to the protocol rules and alignment by block producing nodes for the upgrade to be successfully deployed.Additionally, the State History Plugin has also been promoted to a stable product that is ready for use in production environments.Please note, we recommend all EOSIO Block Producers evaluate and deploy only after reviewing the recommendations provided in GitHub for the upgrade process.This release introduces foundational mechanisms which are needed to facilitate the activation of the consensus protocol upgrade. These mechanisms will allow a two-thirds majority of active block producers of EOSIO blockchains to activate features individually to modify the protocol rules when completing the upgrade. 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 on GitHub.Before deploying the upgrade to any non-test networks, each protocol upgrade feature should be deployed and verified on test networks. 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.An in-depth overview of the protocol upgrade features in this release and their implications to developers and users of EOSIO platforms is available in our initial post announcing the release candidate EOSIO v1.8.0-rc1. We strongly recommend a thorough review and evaluation before proceeding to update to this latest version.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.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.EOSIO™ Version 1.8.0: Stable Release of Consensus Protocol Upgrade Features — EOSIO was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

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.

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.

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.

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.

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.

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.

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.

EOSIO Software Release: Ric...

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

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.

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.

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.

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.

#BuiltOnEOSIO: Effect.AI

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

EOSIO Version 1.7.0:

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

EOSIO Toolkit Update: Demux...

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

#BuiltOnEOSIO: EOS Knights ...

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

#BuiltOnEOSIO: Chestnut Pre...

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

#BuiltOnEOSIO: Opening Up N...

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

Shout out to aspiring block...

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

Four Reasons Why Developers...

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

EOSIO Version 1.6.0:

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

EOSJS Version 20-beta3: Rea...

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

#BuiltonEOSIO: FITBLOX Puts...

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

#BuiltOnEOSIO: Azarus Takes...

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