Free TON

Contest: Ethereum↔FreeTON Bridge Implementation Stage 1

Contest dates

Submission period: 15.12.2020 - 10.01.2021

Short description

Implement stage 1 of the winning architecture of the Ethereum↔FreeTON Bridge Design and Architecture contest with the milestone “Send simple text message between FreeTON and Ethereum blockchains”.

Type

Chained contest

Stages

  1. Send a simple message from FreeTON to Ethereum blockchain and vice versa
  2. Transferring tokens between FreeTON ↔ Ethereum chains
  3. Distribution of relayer responsibilities, economy model implementation
  4. Staking, Rewards, and slashing

Motivation

A significant challenge of blockchains to date is their lack of interoperability. Once a developer builds their decentralized application on any particular platform, they’re generally locked into that platform with no opportunity to leverage any of the benefits of other blockchains.

We believe that the future of blockchain technology is to allow all major networks to interact with one another and to be able to share value and information.

Both ecosystems, Ethereum and FreeTON share these views and we want to add the possibility to interoperability through the cross-chain message-passing protocol, thus we open up many opportunities for awesome projects in the market of DeFi.

FreeTON is delivering a decentralized and fair internet where users control their own data, identity, and destiny. Building a bridge with Ethereum will allow FreeTON to reach a whole new level.

General requirements

  • Cross-chain message-passing protocol with censorship resistance
  • The protocol must have the ability to add methods of decentralized governance (proposals, voting, rewards, slashes)
  • The possibility of trustless and non-custodial transfer of value between networks
  • Open sources of documentation published at GitHub/GitLab or another open repository

Evaluation criteria and winning conditions

Hard criteria

  • Cryptographic primitives: generate key pairs, deriving keys from the seed phase, signing, verify
  • Importing and storing keys from the command line utility
  • Connection to FreeTON node. Send a signed message to the network
  • Voting system, RBAC system, Simple Message Handler, Bridge contract
    • FreeTON contracts should be developed in a distributed style. It means that there should be no case when a single smart contract contains a lot of data in storage.
  • Set of TON-based contracts testing tools. It provides a high-level way to set up your development environment, interact with TON through an external API, and write your integration and e2e test cases
  • Detailed structured documentation for development tools and step-by-step examples to prove deliverables of this stage
  • Relays should not be engaged to actively send transactions to the Ethereum network, due to unpredictable operating costs
  • Smart contracts should have a mechanism for a secure update

Soft criteria

  • Detailed and easily understandable charts explaining the architecture and business processes
  • Brevity
  • Mostly everyday English to facilitate understanding
  • Readiness to participate in the implementation of the solution in the next stage

Artifacts

  • Relay node source code:
    • Cryptography
    • Keystore
    • FreeTON’s node connection
  • FreeTON smart-contracts and Ethereum:
    • Protocol’s smart-contracts
  • DevTools:
    • Smart contract testing subsystem
  • Link to documentation at Github/Gitlab or another open repository, with the obligatory backlink to your submission in the repository’s README
  • Block explorer links to the testing artifacts in the main network

Winning conditions

  • Anyone can participate in the first stage of the contest
  • To apply for the next stage of the competition, you need:
    • take a prize in one of the first three places
    • score at least 5 points in the voting from the jury

Rewards

1 place ………………………. 70 000 TON

2 place ………………………. 50 000 TON

3 place ………………………. 30 000 TON

Voting

  • Jury members who vote in this contest must have a solid understanding of the technology. Those jurors who don’t, should not vote or choose “Abstain.”
  • Jurors whose team(s) intend to participate in this contest by providing submissions lose their right to vote in this contest.
  • Each juror will vote by rating each submission on a scale of 1 to 10 or can choose to reject it if it does not meet requirements or choose to abstain from voting if they feel unqualified to judge.
  • Jurors will provide feedback on your submissions.
  • The Jury will reject duplicate, sub-par, incomplete, or inappropriate submissions.

Jury rewards

An amount equal to 5% of the prize fund will be divided equitably between all jurors who vote and provide feedback based on their votes’ quantity and quality. Both voting and feedback are mandatory to collect this reward.

Governance rewards

An amount equal to 2% of the prize fund will be divided equitably between all governance members.

Procedural reminders to all contestants

  • Accessibility. All submissions must be accessible for the Jury to open and view, so please double-check your submission. If the submission is inaccessible or does not fit the criteria described, jurors may reject the submission.
  • Timing. Contestants must submit their work before the closing of the filing of applications. If not submitted on time, the submission will not count.
  • Contact information. All submissions must contain the contestant’s contact information, preferably a Telegram username by which jurors can verify that the submission belongs to the individual who submitted it. If not, jurors may reject your submission.
  • Content. The content published in the forum and the provided PDF file should not differ, except for formatting. Otherwise, jurors may reject the submission.
  • Well-formed links. If your submission has links to the work performed, the content of those links must have the contestant’s contact details, preferably a Telegram username, so jurors can match it and verify to whom the work belongs. If not, jurors may reject your submission.
  • Multiple submissions.
    • Each contestant has the right to provide several submissions if they contain different approaches to the contest problem’s solving. However, if works are not unique enough or differ just in insignificant details, jurors may reject such repeating submissions.
    • If the contestant wants to make an additional submission that overrides the one previously published, he must inform the Jury about this fact and indicate the correct revision to assess. In this case, only the indicated work will count. If the contestant hasn’t indicated the updated submission as the correct one, only the first one will count, the Jury will reject all the others.

Disclaimer

Anyone can participate, but Free TON cannot distribute Tons to US citizens or US entities.

3 Likes

Following its proposed architecture, Broxus team is really happy to present the implementation of the first stage of ETH-FreeTON bridge.

It consists of three major parts:

  • Relay software
  • ETH smart contracts
  • FreeTON smart contracts

We have also created fungible tokens smart contracts in a highly experimental state.

All parts were tested in conjunction on FreeTON testnet.

We will also organize AMA session and demo at the nearest DeFi group call.

Artifacts

Source code + documentation

DevTools

Contact information

  • Telegram: @sergey_pavlovdog
  • Address: 0:05af9361395067459da792efec735ec225b4acfd4c32e45be37b11ff89d178fe
3 Likes