Select Page
Telos Core Devs Update: October 21, 2019

Telos Core Devs Update: October 21, 2019

Since the September 5th update, the Telos™ Core Developers have been working on numerous projects. We have tried to keep the community updated along the way on important developments. Below is an update on various projects the TCD has been working on.

Trail Voting Progress

The Trail voting service is a major differentiator between Telos and any other blockchain. The Trail 2.0 update will expand the types of voting and committee management tools that Trail offers as well as extending the Trail features from system use only to any token or dapp on Telos. This allows any group to rapidly create state-of-the-art DACs on Telos with very little programming.

Trail 2.0 is undergoing final testing and revision by Craig Branscom and Peter Bue of GoodBlock. New code can be proposed for the Telos mainnet block producers within about a week. Once this is implemented, the Trail 2.0 features will be live for any Telos apps or tokens. However, the Telos voting system for WPS and amendment voting will still use the current system. This is because Trail 2.0 must be live on the mainnet before we can transition our voting to it.

Updating WPS and Amend Voting

The system contracts for WPS (eosio.saving) and amendments (eosio.amend) must be updated to use the new Trail 2.0 system. In updating these, the TCD is suggesting improvements in how these contracts operate. None of these improvements rise to the level of requiring governance changes. However, we want to alert the community about potential changes so that these can be thoroughly vetted before the block producers decide whether to implement them as recommended or request changes. These needed changes were discussed in the September 5th TCD Update under “Governance Changes”.

Revising Telos WPS to Remove Cycles

Telos work proposals include “cycles” which allow the same proposal to recycle multiple times without needing to be resubmitted. While this feature adds some efficiency, the negatives associated with it seem to outweigh its value. Cycles have regularly confused WP submitters despite having clear documentation in both the Github repository and the Telos Users Guide tutorial. Further, multi-cycle WPs eventually drop low on the list below newer proposals which makes them less visible with users forgetting to vote in future cycles. Finally, should the TLOS price experience significant price increases, proposals with multiple cycles may be asking far too much for the work they propose in fiat terms, putting voters in the position of either approving proposals for amounts that are no longer reasonable, or else voting against proposals they would otherwise support due to the cost. Removing cycles from the WPS would resolve these problems and also streamline the function of the WPS contract.

The code that the TCD is currently writing to update WPS voting to the new Trail 2.0 system removes cycles from WPS submissions. If implemented, the TCD would provide a migration plan for any existing proposals but would not allow new proposals to use cycles. Of course, it will be up to the block producers whether or not to adopt these changes, and we expect that they will take their cues from the community. Therefore, we want to notify users of this possible change and request that they discuss it. If the response is strongly against this change so that it looks like the block producers will not adopt it, the TCD will naturally revise the code to reflect the community and block producer desires. Based on initial discussions of this, we expect that it will be well accepted and we continue development with this in mind. For anyone submitting new work proposals, it would be preferable to not use multiple cycles any longer since each of these proposals will need to be included in a migration process.

Provided the community agrees with this approach, updating Telos governance voting to Trail 2.0 should be completed by early November.

Addressing the EOSIO REX Exploit

The EOS mainnet is experiencing occasional performance issues due to a CPU exploit related to REX resource purchases. The TCD proposed a partial solution in Addressing the EOSIO REX Exploit. In short, a reduction in the amount of REX CPU that any single account could purchase will make using this exploit somewhat more difficult for bad actors, and more importantly, encourage Telos apps to maintain a more reasonable amount of staked resources so that they can better endure such attempted exploits. Ryan Jones of Teleology has developed new code to implement the proposed change. This code is now being reviewed and a BP multisig proposal will be issued on the Telos testnet within days to test this. If found to be functional, this same code could be proposed for the Telos mainnet soon thereafter. This new function is configurable to allow the maximum amount of REX CPU any single account can purchase to be changed by a simple BP multisig (as opposed to requiring new code to be deployed). The TCD encourages the Telos block producers and community to discuss whether such a limit is desired by the community and if so, what level is appropriate.

DAC-creation Support Tools

The TCD is working along with other groups to quickly be able to offer additional support tools for the Trail 2.0 voting features. We expect these to make Telos the clear winner for any group considering which platform to build their DAC or DAO on. Groups like SEEDS and others are joining in this effort to turn tools they will use to manage their own DAO into commonly available, open source tools. The Telos Foundation is also doing work in this area to make user accessible voting portals to showcase the power of Telos-based DACs. They currently have Worker Proposal #42 seeking support for their efforts.

The TCD is working in conjunction with these groups. We expect a very powerful suite of tools to allow users to take advantage of these features by mid-November.

Update to v1.8

Previous updates have documented the TCD’s work in aiding the Telos block producers in upgrading the network to EOSIO v1.8. The mainnet upgrade was performed on September 26th at 17:00 UTC, following testing on the Telos testnet and stagenets. This activation, however, only addressed activating the revised v1.8 consensus protocol. Ten other features are also available for activation in EOSIO v1.8. The TCD and Telos block producers published their joint plan to activate these features (Telos Mainnet 1.8 Activation and RFC: Telos Networks Upgrade to Nodeos 1.8.x and New Features Activation). A bug in how missed block are calculated was introduced by changes in how the EOSIO compiler system operates. These were discovered in the testing process and the fix has been implemented. Such fixes are to be expected in the review process and this pushed the schedule back somewhat. However, as of October 21 at 17:00 UTC, the first six of these features are now activated on the Telos mainnet. The remaining four features are proposed to the block producers in the multisig, peter.tcd|phase.two which is scheduled to be executed on October 24 at 17:00 UTC. With these feature activations, Telos is adding important new functionality not yet available on any other blockchain.

Retirement of Telos Testnet A

As previously announced, Telos recently transitioned from the original Telos testnet active prior to the Telos mainnet launch (Telos Testnet A or “Aristotle”) to a new testnet (Telos Testnet B or “Basho”). All testnet monitors currently display Testnet B. On September 16th, the TCD recommended to the Telos block producers to maintain Testnet A for 30 days to allow any apps time to migrate, and then to abandon it. This 30-day period has now passed and Testnet A is expected to expire in the near future.

Implementation Plans for EOSIO 2.0

Block One has released the first “release candidate” for EOSIO v2.0, which is expected to offer new features and a significant increase in processing speed which will mean that apps will require less CPU time to perform the same actions. This will, in turn, further expand the capacity of the Telos networks. It’s possible we will see a 10X — 16X performance improvement. The TCD and Telos block producers are evaluating the various release candidates as they are issued. Some 2.0 nodes are already being deployed on the Telos testnet. Once Block One deems a version of EOSIO 2.0 to be a “release” (ready for mainnet use) as opposed to a “release candidate” (not ready for mainnet use but suitable for testnet use) the TCD will work with the block producers to create a schedule for activation similar to what was recently performed with EOSIO v1.8.

Bancor Contracts Integration

Bancor contracts are smart contracts that allow the automated trading of one token to another without requiring a counterparty. Most Telos users will be familiar with bancor contracts from the purchase and sale of system RAM. Bancor contracts could be used to connect any two tokens. Over the past several weeks, Rory Mapstone of EOSza has been implementing bancor contracts on Telos between the TLOS token and several other Telos-based tokens such as QBE. This allows users to make sales and purchases of these tokens at any time, even without a counter-party. Combined with the system-level DEX order book from Vapaée, this presents a powerful decentralized finance combination that does not exist on any other blockchain at this level. The bancor contracts can be seen on the CoolX wallet now and via other interfaces soon.

USD Stable coin with Onramp & Offramp Integration

The TCD is working with Carbon to integrate Carbon’s US Dollar stablecoin on Telos, TLOSD onto the Telos mainnet. This includes deploying the TLOSD tokens, allowing the purchase and sale of these through the buy.carbon.money website and directly within Telos wallets. Marlon Williams of Telos Miami is working closely with Carbon to integrate all features into a new version of Sqrl wallet, which is expected to offer these features well ahead of the Carbon website. Look for TLOSD in Sqrl by the end of October.

Sentiment Token Integration

Sentiment tokens are a blockchain version of popular social media interactions such as “Like” but they have much more powerful uses, including a reputation function that does not require accounts to opt-in in order to be rated (this is common amongst almost all other forms of blockchain reputation layers). This Telos innovation was first publicly introduced in the article Introducing Sentiment Tokens on October 4th by GoodBlock, however, the TCD first began working on this following the unpublicized release of the Sentiment Token paper on March 12th. We’ve sometimes referred to it as a “secret project”.

Telos Voyager has been working on developing a working implementation of the sentiment tokens for Telos. These will allow users to express their LIKE and TRUST (or DISTRUST) of other accounts visibly for others with the hope that users can be warned off from sending tokens to scammers, among many other uses. This development is advancing well and developers of other tools such as wallets will soon have a system to begin building against.

Gyftie Integration

Gyftie is a blockchain identity project that helps accounts verify their identity as a mesh of other known or verified users. Gyftie has announced that they are deploying on Telos. Already, contracts have been deployed to the Telos testnets and a test version is being used on the Telos mainnet. Within a few weeks we may start to see accounts with Gyftie badges verifying the identities of their owners.

TCD Work Proposals

The TCD’s current work proposal, TCD WP#4 — REX/TEDP Implementation (Telos WP ID 38) will close voting on October 30th at 5:19 UTC.

A new TCD work proposal will be submitted this week for the recently completed work in implementing EOSIO 1.8. Another proposal will follow some weeks later for the work being performed now to implement Trail 2.0 and migrating the existing voting features to it.

There will likely be additional proposals submitted for various projects such as sentiment tokens, bancor contracts, etc.

The TCD still aims to improve its development cycle so that new projects are approved by the community prior to work being performed. To date, this has not been possible because so much of the TCD’s early work was difficult to predict and required swift implementation. As the development cycles are now somewhat more predictable and less urgent, the TCD wants to transition into a more mature payment cycle where users have more say about projects before their execution. However, this will also require the TCD to increase its ranks somewhat with project managers taking on more roles.

Call to Join the TCD

The TCD is eager to expand its ranks. Any developers or code reviewers interested in advancing the development of Telos are welcome to join. All positions are paid via work proposals submitted for actual work performed.

The TCD is also looking for non-developer roles to further its mission. Most needed at present are project managers to track and advance development projects and a communications specialist to help keep the Telos community informed about this work. Interested parties should reach out via the Telos Dapp Development or Telos Testnet Telegram groups or by contacting a member of the TCD.

###

About the author: Douglas Horn is the Telos architect and whitepaper author, and the founder of GoodBlock, a block producer and app developer for the Telos Blockchain Network.

More about GoodBlock can be found at: www.goodblock.io

Join us on Twitter @GoodBlockio

Vote for GoodBlock on the Telos Blockchain Network @goodblocktls

Telos Core Developers — RFC: Telos Networks Upgrade to Nodeos 1.8.x and New Features Activation

Telos Core Developers — RFC: Telos Networks Upgrade to Nodeos 1.8.x and New Features Activation

The various blockchains operating on EOSIO software, including Telos™, have an opportunity to perform an upgrade to the current version, 1.8, which has the potential to cause breaking changes for any node or application on these networks.

Upgrading in Phases

The upgrade to EOSIO version 1.8 comprises two parts. The first part is to upgrade the consensus mechanism. Any nodes not updated to nodeos 1.8 or above will not be able to interact with the rest of the network once the consensus mechanism is upgraded. Block producers running previous versions of the software will fork off the network. Operating nodeos at version 1.8 requires a full replay of the network to sync before the node can activate, which can take several days. For this reason, the TCD and block producers have been preparing for this for some time now. We have made efforts to contact developers of wallets, block explorers, and app developers to make them aware of the proposed time and date of this activation, and have made daily postings of the article describing this initial Telos Mainnet 1.8 Activation timeline.

Upgrading to nodeos v.1.8 also requires updating the EOSIO system contracts to version 1.7.4. This requires additional developer work to ensure that the changes unique to Telos do not provide any unexpected interactions with the new version of nodeos. The TCD are taking this opportunity to also integrate new voting changes to the Trail Voting System v2.0 into Telos governance voting for worker proposals and ratify/amend ballots to re-align the voting weight of various states of tokens (liquid, staked to NET or CPU, staked to REX) to better match their weight in voting for block producers. for these types of ballots to better match the as described in the TCD Update of Sept 5, 2019.

The second part of the EOSIO 1.8 upgrade involves activating any number of new features that are made possible by the new consensus protocol. Many would consider these new features the primary reason to undertake this protocol change, as they offer significant enhancements to the EOSIO software to users and applications.

To facilitate the full value of the EOSIO 1.8 upgrade, the TCD, in conjunction with the block producers has been preparing a migration plan that includes not only the consensus protocol upgrade, but activation of the additional features as well.

Telos operates three types of networks: the Telos mainnet where value is recorded, the Telos testnet, where developers may test their own apps to ensure proper function before deploying to the mainnet, and temporary stage-nets where the block producers test software prior to deploying it to the testnet. Typically, new code is tested in the following order: stage-nets, testnet, mainnet. The proposed migration plan includes actions on all three Telos networks.

Activating Features

The new features provide an array of new functions which can be read about in this article. These new features broadly fall into three categories: “Safe changes” that will cause no errors or breaks in existing apps, “Breaking changes” that will cause program errors only in apps that use the previous versions of these features.

This migration plan intends to lay out a schedule for deploying these changes across the various Telos networks so as to test and rehearse them for block producers (on stage-nets), provide them for developers for testing and modifying their own apps (on the Telos testnet), and finally to deploy them to the Telos mainnet for general usage. A period of time has been provided between each activation to allow observation before additional changes are made.

These features fall into the following categories:

Safe Features

· ONLY_LINK_TO_EXISTING_PERMISSION

· FIX_LINKAUTH_RESTRICTION

· DISALLOW_EMPTY_PRODUCER_SCHEDULE

· ONLY_BILL_FIRST_AUTHORIZER

· GET_SENDER

· RAM_RESTRICTIONS

· FORWARD_SETCODE

Breaking Features

· REPLACE_DEFERRED

· NO_DUPLICATE_DEFERRED_ID

· RESTRICT_ACTION_TO_SELF

RESTRICT_ACTION_TO_SELF

The proposed phases of this migration are:

1. Consensus protocol

2. Activation of safe features in one group

3. Activation of remaining safe features

4. Activation of breaking features

Proposed Rollout Schedule

The following chart details the proposed upgrade schedule for all elements discussed. Features activation on the Telos testnet will occur in a phased rollout, but all on the same day so as to provide app developers the maximum amount of time to modify and test their apps.

Proposed Rollout Schedule for Telos networks

###

About the author: Telos architect and whitepaper author Douglas Horn leads the Telos Core Developers. He is the founder of GoodBlock.io.

Telos Core Developers Update

Telos Core Developers Update

September 5th, 2019

The Telos Core Developers have been working on a number of crucial projects over the past several weeks and have a roadmap for work ahead to share in this update.

TCD Worker Proposal #3

The TCD WP #3 was overwhelmingly approved by the Telos voters. Voting closed on August 22nd and the funds have been claimed and disbursed to CalEOS, TheTeloscope and EOSphere Devs. Thank you for your support!

Future TCD WPs

Changing Funding Approach

With its first three worker proposals, the TCD has been requesting payment for work already completed as bulk packages. Essentially, all work delivered over the preceding weeks was aggregated and payment requested in a single lump sum which was then distributed to contributors. However, some people in the Telos community have asked that this process be changed. Specifically, they would like for projects to request payment prior to performing work, and for different projects to be submitted individually for voting.

This seems like a reasonable request and we are working towards adopting it. The TCD will immediately begin submitting individual WPs for different projects. Moving towards requesting payment/approval in advance is likely to require more time. Since the launch of the Telos mainnet, the TCD has needed to perform work in advance of payment because, frankly, we needed to complete some of the tools that allow WPS to function properly. Later, we worked on projects that were necessary nearly immediately and could not easily wait for prior approval without slowing the growth of the Telos network. From this starting point, there is still catch-up needed before we can request approval prior to performing the work. There’s currently a backlog of work that was performed over the past several weeks to discover the cause of the Telos testnet malfunctions and to enable the TEDP and REX staking.

Changing our WP approach from requesting funding in arrears to requesting funding in advance means that there will be a period when the TCD is requesting high amounts of funds in one period of time. It is probably best, then, to make this a time when there has either not been a large amount of work done recently in need of payment, or when there is little work on the immediate horizon. At present, the TCD has just completed a large amount of work and also has a fair amount ahead in implementing the changes needed to prepare for the EOSIO v.1.8.x upgrade. Finally, when requesting payment in advance, it can be hard to gauge the amount of work that will be needed and exactly who will perform that work. Therefore, we hope to continue to request payment in arrears until the EOSIO v.1.8.x upgrade is completed. Following this, there may be a short gap in immediate development work needed, which would be a good opportunity to make this switch.

Telos Testnet Postmortem

In TCD WP #3, funds were allocated for the work CalEOS led to restore the corrupted Telos testnet. Prior to making any upgrades to the Telos mainnet code that would be required for implementing TEDP, REX or the EOSIO v.1.8.x upgrade, it was necessary to fully understand the cause of the malfunction that occurred on the testnet so that there was no chance it would be reproduced on our mainnet when new code was deployed. Therefore, a concerted effort to perform a postmortem on this malfunction was launched which ultimately discovered the cause and allowed us to upgrade the mainnet without fear of problems. An ancillary benefit of this was that our organization has been improved towards the coordinated effort that will soon be necessary for upgrading to v.1.8.

GoodBlock, CalEOS, and EOS USA performed the bulk of the work needed to correct this problem. The TCD will be submitting a WP on their behalf for this work shortly.

TEDP and REX Implementation & Merge

Implementing the new features of the Telos Economic Development Plan and REX staking required new code to be written, tested, and reviewed. At this same time, code that had been previously written but not merged into the Developer or Master branches of the Telos Github repository due to questions surrounding the testnet postmortem also needed to be reviewed and updated. This merge also had the benefit of updating the Telos code repository once again in the eyes of casual viewers.

GoodBlock led this effort with assistance by CalEOS. Telos Miami and Teloscope also provided important code review. The TCD will be submitting a WP for this work shortly.

Trail Voting 2.0 Upgrade

Telos uses an auxiliary voting system to power its WPS, Ratify/Amend, and other voting. This system, called the Trail Voting System, is now being upgraded to version 2.0 which includes additional methods of voting, committee tools and more. More revolutionary, Trail 2.0 extends these governance functions to any app on Telos that wants to use them and manages them at the system level. These new functions are extremely exciting for turning Telos into a leading blockchain for any developers or groups who want to easily create and manage DACs, DAOs, and “dBusinesses”. We see this as a major new selling point for Telos and it is already attracting dapps.

To date, the Trail Voting System has been an innovation from GoodBlock developers with outside code review from Telos Miami and TheTeloscope. The TCD will be submitting a WP for this work shortly.

RFC: Telos Mainnet 1.8.x Upgrade & Roadmap

On September 4th, the TCD submitted a Request for Comment document regarding its suggested process and roadmap for upgrading the Telos mainnet to 1.8.x in September. We look forward to comments from block producers, app developers, wallet and explorer operators, and the Telos community. Upgrading to 1.8 gives us a lot of important new features, but it means that every node on the network will need to be upgraded in a coordinated way. Please share your thoughts as we work toward a plan that supports the community’s needs.

https://medium.com/@goodblock_info/rfc-telos-mainnet-1-8-x-upgrade-process-roadmap-307d43a905ee

Governance Voting Change Proposed

Telos uses an auxiliary voting system called the Trail Voting Service for all forms of voting besides the standard block producer voting that is native to EOSIO. As was previously reported, the initial implementation of this voting system counts all TLOS in an account toward vote weight (liquid, and staked for CPU or NET resources). This is different from how block producer voting works, where only TLOS staked for CPU or NET resources, but not liquid TLOS, are counted towards voting. This system also required ongoing balancing of votes through the eosio.trail “mirrorcast” action to reduce the gameability of this voting. Trail voting also does not allow voting by proxies, as block producer voting does. Therefore, it has long been the TCD’s intention to revise this voting in future updates to both better reflect how block producer votes are cast and to remove the need to constantly balance token values.

When the code for REX was implemented, one consequence was that TLOS tokens staked to REX no longer counted towards voting for Trail ballots such as WPS. This is because Trail voting includes liquid, CPU- and NET-staked TLOS (but not REX-staked), whereas block producer voting includes CPU-, NET- and REX-staked TLOS (but not liquid). As more an more TLOS are staked to REX, this changes voting and may make it more difficult for some ballots to reach their minimum thresholds.

The TCD consulted with the Telos block producers about how to best address this situation and the unanimous recommendation of all who voted was to revise Trail voting to better match block producer voting at this time. This change means Trail ballots will no longer count liquid token balances, but will count TLOS staked to REX, CPU, or NET just as block producer voting does. However, Trail voting does not yet support proxy voting. Implementing that feature will require more time and would delay the implementation of the proposed change. This work is expected to be complete along with the process of updating the mainnet to v.1.8.x.

About the author: Douglas Horn is the Telos architect and whitepaper author, and the founder of GoodBlock, a block producer and app developer for the Telos Blockchain Network.

More about GoodBlock can be found at: www.goodblock.io

Join us on Twitter @GoodBlockio

Vote for GoodBlock on the Telos Blockchain Network @goodblocktls

RFC: Telos Mainnet 1.8.x Upgrade Process & Roadmap

RFC: Telos Mainnet 1.8.x Upgrade Process & Roadmap

Block One has released code for an important upgrade to EOSIO v.1.8.x. This system upgrade enables several new features in EOSIO and is necessary for following the ongoing upgrade path in the future. However, it is important to note that this is a hard fork in the consensus protocol of the EOSIO software, meaning that EOSIO v.1.8.x cannot interoperate with previous versions without creating forks in the chain. Therefore, it is necessary to first rehearse this process on our testnets and stagenet and to coordinate the process on our mainnet to ensure proper operation of the Telos mainnet and all of the block explorers, wallets and applications operating on it.

All nodes running on Telos will need to upgrade to EOSIO v.1.8.x and replay their nodes, which will be time consuming. Block producers need additional coordination. Block One has provided a technical guidance document detailing best practices for all nodes operating on the Telos blockchain. 1.8: Consensus Protocol Upgrade Process.

To facilitate this coordinated effort and elicit comments from the Telos community, the Telos Core Developers propose the following roadmap for updating the Telos mainnet to EOSIO v.1.8.x. Please contribute your thoughts and ideas to improve this and help us work toward a shared schedule. It is in some ways fortunate that the Telos Core Developers and several block producers recently needed to coordinate efforts in discovering the root cause of an error in the Telos testnet (A, or Aristotle) because this provided valuable experience in coordinating these efforts that can be put to good use in the upgrade to EOSIO v.1.8.x.

Note: “Basho testnet” refers to the new Telos testnet (B) which was recently created and which will become the Telos testnet of record at some date in the near future. “Stagenet” refers to one of several private testnets for Telos block producer usage in testing new software or rehearsing coordinated system upgrades. Future dates indicate the earliest and/or proposed times for each milestone

TCD Roadmap

Work Already Completed

eosio.contracts v1.6 — Merge Github repository
eosio.system v1.6 — Unit Testing and regression testing
eosio.system v1.6 — Basho Testnet upgrade
eosio.system v1.6 — Mainnet upgrade
eosio.contracts v1.7.x — Merge Github repository
eosio.contracts v1.7.x — Unit testing and regression testing

Upcoming Work

September 2–6

trail-service 2.0 — Deploy on Basho testnet
eosio.saving v1.7.x — rewrite for use with trail-service 2.0
eosio.amend v1.7.x — rewrite for use with trail-service 2.0

September 9–13

eosio.saving v1.7.x and eosio.amend 1.7.x — Unit testing and regression testing
eosio.saving and eosio.amend — Basho testnet upgrade
– At this point, all Telos block producers must spin up a v1.8.2 node on both the Telos mainnet and the Basho testnet and replay the respective chains. This is required for the eosio v1.8.2 upgrade and eosio.system v1.7.x upgrade as referenced in the Process document.

September 16–20

eosio v1.8.x and eosio.contracts v1.7.x — Stagenet deployment(s) (via coordinated BP action)
trail-service 2.0 — Stagenet deployment(s) (via BP multisig transaction)
eosio v1.8.2 and eosio.system v1.7.x — Basho Testnet upgrade (via coordinated BP action)

September 23–27

trail-service 2.0 — Mainnet deployment (via BP multisig transaction)
eosio.saving and eosio.amend — Mainnet upgrade (via BP multisig transaction)
eosio v1.8.x and eosio.system v1.7.x — Mainnet upgrade (via coordinated BP action)