Swingby SkyBridge testnet is now live — Try it here: Swingby Skybridge

Until now, the Swingby Protocol approach was primarily a method of issuing tethered stable coins based on financial engineering.

However, that approach required many actors, presented a technical hurdles in user experience, and was based on the same system requirements as makerDAO’s DAI; securing assets on the cross-chain at the same time requires very advanced crypto-economics.

For example, sufficient surplus in collateral, and trying to keep Bitcoins locked using HTLC. Maintaining such rationality, economics, and system integrity over time has shown to been very hard.

Our approach goes back to a simpler solution, and removes the need for complex smart contracts.

Up until the second half of 2018, it was difficult for assets on the cross-chain to hold equivalent assets (pegged coins) on different chains due to several hurdles.

There was a turning point in the second half of 2018, to 2019 when there was a big breakthrough that split the ECDSA signature among multiple people, enabling the same functionality as multi-sig. This solution is open to anyone, regardless of the size of the signature.

At the same time, research on initial secret sharing to construct sMPC (secure multi-party computation) and re-group technology that dynamically reorganizes secret shares between parties are also evolving.

With these breakthroughs in place, we are announcing a simple service — Swingby Skybridge — that allows you to connect Bitcoin to almost any blockchain.

Swingby Skybridge

Swingby Skybridge connects two different chains and provides a two-way Token Bridge.

We adopted a completely new architecture that is radically different from the previous Swingby proposals.

This mechanism is realized mainly by using the ECDSA threshold signature by TSS (threshold-signature scheme) and Proof of Stake.

By combining these two technologies, Swingby Skybridge creates a highly decentralized P2P network.

One multi-sig address that spans two chains is constructed, and one TSS custody address is constructed by the selected upper nodes based on the Proof of Stake consensus model.

Such a decentralized multi-sig address is a storage location for token movement across bi-directional chains, and end-users can receive Bitcoin tokens in the target chain simply by sending Bitcoin to the input Bitcoin chain address.

For P2P node consensus, a consensus model (leader-less consensus model) that does not have its own leader is adopted, and a security model equivalent to BFT consensus is provided only by incentive design. The implication is that it is more efficient than the BFT consensus because it does not require extra messages.

Please refer to the White Paper for details on the architecture. Details

Swingby Node — TSS Staking Node

Start a Swingby Node and join the Swingby network to earn Staking rewards.

To do this, start a Swingby Node, deposit Swingby Tokens and stake them. You can then become the signer of the TSS custody address.

Signers participate in the TSS custody address’s Signing Round by raising the staking rank. At the end of the signing round, the signer can receive a commission depending on the network contribution.

The more Swingby Nodes, the stronger the network and the more reliable the protocol. The more reliable the protocol, the better the security of the TSS custody address and the higher likelihood of increased swap volumes.

In addition, For the initial growth of the network, we will distribute additional staking rewards to early adopter staking users.

The decentralized BTC token

One of our major milestones is the realization of a decentralized BTC token. This realization is now within our grasp.

Historically there has been no realization of decentralized custodians, but this is now feasible today. The connection of decentralized BTC tokens to a DEX is an indispensable piece for any DEX and supporting service protocols will contribute to increasing DEX trading volume.

In particular, the first blockchain we connect to will be the Binance chain, and it is highly likely that the liquidity will be greatly increased with Binance DEX BTC as the base currency.

We believe that in the future, we will support many blockchains and eventually bridge any asset on any chain.

Swingby Token (SBY)

Swingby Token is the backbone of the Swingby Network consensus engine and the staking currency required for Swingby Nodes to join the network. As mentioned above, SBY needs to be staked by the Swingby Node operator. Nodes can earn rewards for transaction fees, but they will be BTC or BTC.B for now. In the future, the staking amount will be fixed and the nodes will be exposed to competition. It is planned that the amount will be automatically traded and the node payout will be paid in the native SBY token. In addition, the amount of SBY-BEP2 token is fixed at the initial stage and no additional issuance will be made, though tokens will both be lost in normal attrition, and possibly burned at later stages to tighten circulating supply.

What is the future of Decentralized Custody Engines?

I believe that the idea of decentralized custody engines will be the main topic of 2020. Several projects are already working on this topic, but don’t forget that they have various dependencies. For example, reliable decentralized oracles are needed to get the market price of a coin to be custodied.

We are testing a confidential cloud with several decentralized and trustless oracles and working on economic models of putting them to use. There are several such real-world application options, such as the decentralized Oracle (e.g. ChainLink), that exist today.

We continue to explore every option and are working towards a testnet release of these solutions soon

Yasuka Senga

CEO — Swingby

Disclaimer:

This report is prepared for general circulation. It does not have regard to the specific investment objectives, financial situation and particular needs of any specific recipient of this report. You should independently evaluate particular investments and consult your independent financial adviser before making any investments or entering into any transaction in relation to any securities or investment instruments mentioned in this report.
The information and material presented herein this report are not directed at, or intended for distribution to or use by, any person or entity who is a citizen or resident of or located in any jurisdiction where such distribution (in particular citizens or residents of the United States of America or Japan who are not allowed to directly purchase or publicly be allocated any online tokens or cryptocurrencies), publication, availability or use would be contrary to applicable law or regulation or which would subject us to any registration or licensing requirement within such jurisdiction.

The new Swingby was originally published in Swingby Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nobody likes a copycat. At Swingby we were disappointed to see some FUD this week that we were copying from other projects, and so we’d like to address a few things quickly.

Swingby is a unique protocol, custom built by our developers from the ground up. We have been working on this protocol for over a year and our GitHub commits show this: Swingby witness component and Swingby Protocol Spec one and Multi-hash timed lock contract.

Swingby is dedicated to solving cross chain swaps in a trust-less protocol, and whilst there are many other teams working on the same challenge, we are solving a similar but distinct problem that requires a similar but distinct solution.

It was recently brought to our attention that the external contractor we used to design our website had taken and repurposed a graphic of another blockchain platform. This is regrettable and as soon as this was brought to our attention we removed the graphic and have parted ways with the designer. But we own this mistake. We could have been more diligent in our screening and checking, and we have put in place processes to prevent this in the future. We will also be rebuilding the website as part of our ongoing development.

As we launch our Test network, we are fully committed to open sourcing our entire codebase, which will show that all of our product is custom built, with the exception of the Binance Chain TSS libraries we use. If we leverage other open sourced projects in the future, we will communicate that to the community with full transparency at that time.

As younger players in an already very young industry, we hope to work together with all providers, including those we may have inadvertently upset today, to grow the ecosystem and present users a rich diversity of choice.

At Swingby, we stand fully behind our development and the solutions we are building for users, and we are excited to grow this space together through 2020 and beyond.

Nobody likes a copycat was originally published in Swingby Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

(English post is here)

数日前、Ethereumの開発者Vitalik Buterin氏によってDAICOが発表されました。DAICOで提案されているビジョンは、フェアなICOの未来を示しています。また、我々の開発するICOフレームワークであるRICOの思想と共通している点が多く、とても興味深いものです。

そこで私たちは、DAICOの最初の実装となるコードを書き、公開しました。これは、分散型のICOフレームワークであるRICOをベースに書かれています。具体的な実装をGithubで見ることができます。

DRI-network/RICO

注意：これは現在開発中のものであり、バグが含まれている可能性があります。

DAICOとは何か

これまでのICOには、詐欺的なICOや、資金調達後に全く進行が見られないICOが多く存在してきました。その理由として、プロジェクトが一度資金を集め終わると、その後は開発を進めることに対し何の義務も負わなくなってしまうということが要因として挙げられます。

上記の課題を解決するために提案されたのがDAICOです。DAICOは、「投資家がプロジェクトの資金利用プロセスに投票を通して関わることで、資金の持ち逃げを防ぐ」という技術的アプローチのアイデアです。

DAICOでは、これまでのICOの仕組みと違い、セールで集めた資金がロックされ、全額を最初から利用することはできません。代わりに、集めた資金の中から毎月一定額の資金だけをプロジェクトが引き出せるようになっています (この引き出せる割合を”Tap”と呼びます)。また、このTapの設定は投資家がトークンを用いて投票することで変更することができます。

さらに、プロジェクトが詐欺であることが明らかになった場合、投資家の多数決による投票でプロジェクトのファンドを停止させ、資金の払い戻しを行うことができます。

上記の仕組みにより、技術的なアプローチで投資家保護の実現を目指すのがDAICOのアイデアとなります。

DAICOの実装提案

Vitalik氏の投稿はあくまでアイデアであり、実際の実装についてはほとんど言及されていません（DAICOのコンセプト原文の翻訳についてはtakashiさんの翻訳記事をご覧ください）。そこで、我々はDAICOを実装するにあたり、独自の解釈を加えています。

RICOが実装したDAICOのアーキテクチャをご紹介します。

Contribution mode

DAICOでは、ICOにおける寄付期間のことをContribution modeと呼んでいます。RICOではContribution modeの受付方法として、すでに以下の方法をサポートしています。

・ キャップ付きセール
・ キャップなしセール
・ ダッチオークション

RICOでは、Proof of Donation (“PoD”)というモジュラーシステムを採用しています。 PoDは、寄付のタイミングに応じて呼び出されるモジュールであり、ICOの機能を簡単に拡張することができます。これにより、DAICOで想定されている他のセール形式(Interactive Coin Offering や KYCありのセール)もサポートすることができます。

今回の仕様はDaicoPoDとして実装され、他のProof of Donationベースのコントラクトとの併用を想定しています。
DAICO PoDのコードはこちらから見ることができます。 https://github.com/DRI-network/RICO/blob/daico-pod/contracts/PoDs/DaicoPoD.sol

How to vote

DAICOは、トークン保持者の投票によりICO終了後のプロジェクトの規律を作ります。私たちは投票の方法として、トークンを投票用コントラクトにデポジットする方法を採用しました。

• 投票プロセスに参加するには、最低15,000 Tokenをデポジットしている必要があります（このトークン量はあくまでサンプルです。最適なトークン量はこれから検討が必要です）
• 参加者は期間中に以下で示すvote関数をコールします。
• 投票したアカウントのトークンがその期間の間ロックされます。（引き出し不可）

function vote(bool _flag) public returns (bool);

Proposing a vote (Raising the tap or go into Withdraw mode)

DAICOでは、トークン保持者の投票により以下の2つの行動ができます。

• 開発チームが一定期間にコントラクトから取り出せる金額(Tap, 単位: wei / sec)を上昇させる
• withdraw modeに移行し、トークン保持者がICOコントラクトに残ったETHを引き出せる(コントラクトの破壊)

Tapの上昇や、withdraw modeに移行するためには、コントラクトにプロポーザルを送信する必要があります。私たちの実装では、これにsubmitProposal関数を利用し、新しい提案を作成します。この関数は、前回の提案が集計された後に実行することができます。submitProposalを実行できるアカウントは、最低30,000 Tokenをコントラクトにデポジットする必要があります。（このトークン量はあくまでサンプルです）

また、aggregateVotes関数は、submitProposalによって定められた投票期間が終了している場合に、だれでも実行可能です。プロポーザルの集計結果に基づき、Tapを上昇させるか、もしくはwithdraw modeに移行します。

submitProposal関数とaggregateVotes関数は以下のように実装されます:

function submitProposal(uint256 _nextOpenTime, uint256 _nextCloseTime, uint256 _nextTapAmount, bool _isDestruct) public returns (bool);

function aggregateVotes() public returns (bool);

submitProposal関数のパラメータは以下の通りです:

• nextOpenTime : 新しい提案の投票開始時間
• nextCloseTime: 新しい提案の投票終了時間（nextOpenTimeから最低7日後以上の指定が必要です）
• nextTapAmount : 新しい提案で有効になるTapの量
• isDestruct: この提案をwithdraw modeに移行することを目的にするかどうか（ファンドを消滅させます）

Withdraw mode

投票によりwithdraw modeが可決された場合、コントラクトは新規のトークンデポジットを禁止します。
以下の計算式により、すでにデポジットしているトークンの残高に応じて、ETHを引き出すことが可能です。

uint refundAmount = this.balance * lockedTokenBalances[msg.sender] / token.balanceOf(this);

Risk

悪意あるプロポーザル提出による妨害
懸念される点として、submitProposal関数を実行できるアカウントが悪意を持っている場合、意図的にコントラクトに悪意のあるプロポーサルを送信し続けることが可能であることが挙げられます。
これに対して、懲罰アルゴリズム（Slasherや、適切なBurn model）などの機能を追加する必要があるかもしれません。

コードの全てはこちらから見ることができます。 https://github.com/DRI-network/RICO/tree/daico-pod
Note: DAICO 及び DAICO PoDはまだ完璧ではありません。このアーキテクチャは今後変更される可能性があります。

RICOについての質問や議論は、Github IssueやDRIのCommunity Slackでお受けしています。 https://dri-slack.now.sh/

About DRI
DRIは、東京をベースに Ethereumを中心とした分散技術の研究・開発を行うDAO型コミュニティーです。 mail: info@dri.network
website: https://dri.network/

DAICOの最初の実装を公開しました was originally published in DRI Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

この文章は、ICOフレームワーク RICO Framework の version 0.9.1 のリリースノートです。このバージョンはアルファ版です。ご利用に際して損失を被った場合でも、このバージョンでは一切保証されません。

新たな機能

• コントラクトによる資金分配機能の追加
• Raiden-NetworkのDutch Auction形式の価格決定アルゴリズムを追加

いくつかの修正

• external functionのバグfix
• AddMarketMakerの削除
• より安全なエスクロー設計に変更
• RICOのリファクタリングとLauncherの変更

RICOはここ２週間で大きく前進しました。コードテストを強化し、多くのシナリオテストを実施しています。予定では、あと２週間でコードの完全な監査を終え、実証実験を行う段階に移行できます。

1. コントラクトによる資金分配機能

RICOの以前のバージョンにおいて、寄贈されたすべてのETHは直接Gnosis-Multisig-Wallet（以下 、GMW)に転送されていました。この場合、多くの資金が一度にプロジェクトオーナーに渡ってしまうことになります。これでは大規模な資金を得たオーナーが開発モチベーションを維持できず、成果物を出すまでプロジェクトを継続できないといった問題を引き起こす可能性がありました。

10億集めたICOが何もプロダクトをローンチできない理由 | ビットコインの最新情報 BTCN｜ビットコインニュース

この問題に対し、RICOの初期の構想ではMultisig Walletのみでもモチベーションを維持するガバナンス体制が構築可能ではないかと予測していました。しかしその後、

Tezos Raised $232 Million in a Hot Coin Offering, Then a Fight Broke Out

Tezosプロジェクトにおいて大規模な内紛が発生します。この状況を鑑み併せた結果、GMWの実装のみでは、プロジェクトオーナーの権限を縛りプロジェクトを維持することは難しいとの結論に至りました。（Breitman夫妻は、全資金を動かす権利はプロジェクトオーナー側にあると考えており、勝訴することができれば資金の分配を強制できる可能性が高いと目論んでいる可能性があります。）

そこで今回のアップデートでは、寄贈されたETHのうち、引き出し可能なETHのスケジュールを明確に定義することで、任意のタイムスケジュールで資金をRICO ContractからGMWに移動させる機能を追加しました。

これにより資金は一時的にContractにロックされた後、徐々にプロジェクトオーナー側に移って行くという動作が実現します。プロジェクトオーナーは仕組み上、一度に資金を移動させることができず、プロジェクトの成功に対して明確な意思を持つことを強制されることになるため、内紛リスクを抑え、プロジェクトオーナーのモチベーションを維持できるようになり、チームの生産性の向上に繋がる可能性もあります。

function AddWithdrawalRoundはコントラクトから資金を引き出す予約を行うためのメソッドです。コードは以下の通りです。

ここでcalcTotalWithdrawalWeiはTOB時の最大ETH量、またはProof of DonationのETH総量を最大値に設定できます。また、予約した引き出し命令を実行するメソッドがfunction execWithdrawalRoundです。コードは以下の通りです。

この機能はVersion 0.9.1 で実装されています。また、今まで別途定義していた function AddMarketMaker を統合することで、シンプルなロジックにリファクタリングされました。

加えて、マーケットメイカーへの分配についてはプロジェクトオーナーが実行するため、今まで通りマーケットメイカーはプロジェクトオーナーと適切なコミュニケーションを取る必要があります。

2. Raiden-Dutch Auction方式の価格決定アルゴリズムを変更

Raiden Network - Fast, cheap, scalable token transfers for Ethereum

RICOフレームワークでは、Gnosis-ProjectのDutch Auction方式から、Raiden-NetworkのDutch Auction方式に変更する修正を実施しました。Raiden-NetworkのDutch Auction型のICOは現在進行中です。いまのところ、以下の理由からRaiden-NetworkのDutch AuctionではFOMOの問題をクリアしているように見えます。

Gnosis-ProjectのDutch Auctionは、価格決定が経過時間のみに偏っているのに対し、Raiden-Networkでは寄贈されたETHの総量に比例した決定方式を採っています。

また、Gnosisでは期限を定義してあったことに対し、Raidenでは期限の制約がなく、目標金額に到達するまで無期限です。長期的な価格決定を行えるRaidenの方が、よりプロジェクトの評価がしやすい（プレディクションマーケット作用が大きい）と判断しました。

Raiden方式の問題は、寄贈されたETHの量があまりに少ない場合、永遠にDucth Auctionが終了しないことです。この問題を解決するためには、価格減少関数を適切に設定すること、具体的にはStartPriceを適切に設定することが必要です。

また、function claimToken を追加しました。これにより、RICO Contract側からTokenを生成可能にし、Tokenを予約する機能を追加しています。

Dutch Auctionのコードはこちらから確認できます。

DRI-network/RICO

次回のアップデートに向けて

RICOフレームワークの次回のアップデートでは、より品質を向上させた状態に移行します。また、以下のような機能を実装予定です。

• 参加者のWhiteList追加機能
• ERC223 Token Standardの追加または置き換え

RICOの開発を進めていくにつれ、RICOは現状のSolidityアプリケーションの中でも大型のアプリケーションとなって行くことを懸念としてきました。

Etheruemのマシンスペックは、マイナーのコンセンサスでターゲットされるBlock Gas Limitによって指定されます。１ブロックあたりの処理能力（ブロックサイズ）はGasとBlock Gas Limitに依存します。

たとえば、Ethereumの大規模なテストネットワークの一つであるRopsten-Testnetでは、MetropolisハードフォークによってBlock Gas Limitを4,700,000 Gasとする仕様変更がありました。そのため、Ropsten-Testnetでテストする場合、Solidityで一度のTxで実行可能な処理は4,700,000 Gasを超えることはできません (GasLimitを超えたアプリケーションのfunctionは永遠に実行できません)。このような制限は、今後のHF時に脆弱性を産む可能性があります。今後、Ethereumのハードフォークに合わせた適切なアプリケーションの設計を心がけ、各機能をできるかぎり低コストで実行可能になるよう慎重に設計する必要があります。

— —

DRIは、RICOフレームワークを通して分散型技術を広く利用する社会の実現に向けて活動を進めてまいります。

RICOのリポジトリは以下からご覧ください。

DRI-network/RICO

RICO version 0.9.1をリリース！ was originally published in DRI Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.