pEOS (PEOS)の編集履歴#3

それは燃えるような速いです

pEOSはEOS上に構築されており、0.5秒のブロック時間を最大限に活用します。EOSテクノロジーに基づいて構築されたプライベートトランザクションをお楽しみください。

それはPEOSとなる。

DEX互換

PEOSは、本質的にEOSトークンであるため、DEXと完全に互換性のある最初のプライバシー中心のトークンです。それを止めることも、追跡することもできません。それは私たちが約束した革命です。

ネイティブECC実装とEOSVM

ここでは、楕円曲線暗号を実行する場合のネイティブコードと比較したEOSVMのパフォーマンスに関する調査結果を示します。ここに示されている証拠は、EOSIOでのEC組み込み関数の実装に関するEOS改善提案をサポートするためのものです。

パフォーマンスを比較するために、EOSIO用にコンパイルするのが簡単で、多くの変更を加えることなくコントラクト内で実行できる単純なECCライブラリを使用します。これは、数学的最適化と事前計算が不足しているため、pEOS実装では使用しませんが、同じコードを実行しながらパフォーマンスを比較するのに非常に適しています。

ライブラリはhttps://github.com/ANSSI-FR/libeccからダウンロードできます。

ライブラリには、ランダムデータの歌と検証のベンチマークを提供するテストスイートが含まれています。つまり、プログラム：src /ec_self_tests.c。このプログラムは、ライブラリを初期化し、キ​​ーペアを生成し、300の署名とそれらの署名の検証を実行します。以下に、ベンチと呼ばれるEOSコントラクトアクションとして実装された同じコードを示します。

https://medium.com/media/eb5b4b8d8ff1daa268873444b576f7fd/href

Running the default native implementation of the benchmark we get around 250 signatures/sec. The same code running interpreted by EOSVM, with the node running on the same machine, fails to finish within the transaction time limits imposed by the system. As a matter of fact the code gist above only attempts to do one signature (not 300 like the original test).

So the results of the benchmark can be summarized below:

Native signature: 4ms

EOSVM signature: >30ms

We think the results speak for themselves.

Conclusions

EOSVMは、Webアセンブリの解釈において大きな一歩を踏み出し、場合によっては桁違いに優れたパフォーマンスを提供します。ただし、計算量の多いEC計算を行うと、システムに負担がかかる可能性があります。ブロックチェーンの暗号化の性質と、最近EOSIOのパフォーマンスで見られた問題を考慮すると、高度な暗号化dappがネットワークを効率的に使用できるようにすることが最も重要であると考えています。

*テストはEOSIOv2.0.0-rc2を使用して実行されました

ウェブサイト：https://peos.one

電報：https://t.me/pEOSone

電報中国：https://t.me/pEOS_china

ツイッター：https://twitter.com/peos_one

GitHubの：https：//でgithubの.com / peosdev

続きを読む

pEOSステータスアップデート

フォロワーの皆さん、こんにちは！初めてスケジュールが少し遅れていることに気づいたと思いますので、ステータスを更新する必要があると思いました。

ご存知のように、10月中にメインネットでローンチする予定でした。いくつかのEOSIOの遅延に関係なく（たとえば、最初の計画では、1.8か月前にEOSIOを期待し、現時点ではEOSVMで2.0にホッピングしています）、メインネットの準備ができており、セキュリティ監査を終了しています。私たちはこの発表をしました、そして…あなたが知っているように…すべての地獄は解き放たれました。発表直後、EOSメインネットは輻輳モードになり、テスト展開が必要かつ予想されるよりもはるかに面倒になりました。ありがたいことに、REXを使用すると簡単になりますが、それでも、物事ははるかに高価になり、テストに時間がかかります。

This made it obvious to us that eventually, we will have to start pushing one of our alternative implementations of the pEOS technology. One that requires some changes into the EOSIO system itself. We initially didn’t push for those as it would require Block.one to implement/approve these, and it would make it very unpredictable to estimate and plan for. Instead we pulled every rabbit from our sleeves and used every trick in the book of code optimization to make pEOS possible without any native cryptography support. So after witnessing the quick growth of the network and the future need for further optimization, in parallel to the launch and to lay the ground for this, we posted our first EOS Improvement Proposal: https://medium.com/@pEOS_one/eos-improvement-proposal-8148480043b6 after Dan Larimer’s suggestion.

What would change with the above proposal, I hear you ask. Well, pEOS transactions will become orders of magnitude more efficient on CPU usage. This was not a problem on a normally operating EOSIO network, but right now it’s a necessity. We made attempts to adapt to the situation by capping the ring sizes for launch, and after 1.8 to maybe have us (the pEOS team) take up the CPU costs for the users. We quickly adapted the system to do it this way so we can launch with a usable pEOS system, but then the situation revealed itself at its full glory…

Right now, for example, it would take approximately 170 EOS staked to run a single pEOS transaction! And then you can’t run a second one for 3 days. Of course, there is REX that was a kind of solution, but the last days even that runs out… quick sand… So even with the team paying for the cost there is now not enough REX!!! It’s evident that we need permanent solutions and not to keep playing hide and seek with every problem EOSIO throws at us. Native cryptography operations as described in the proposal will allow for orders of magnitude less CPU needed, and bigger ring sizes that make the system more secure.

Therefore now the implementation of the improvement proposal is of paramount importance. The delays in EOSIO improvements (mostly in adoption), along with the ever-accelerating EOSIO usage, made it so that it’s now mandatory to have these cryptographic operations in the core in order to have a functional and usable system.

I call everyone to be patient and allow all the dapps that are facing similar problems to find solutions to rectify the situation. Every single project on EOS contacted us about using the pEOS technology, and we know first hand the deep need for what pEOS is bringing to the table. Therefore we know most dapps are struggling right now. The pEOS team is not giving up. We stick to our plan and try to solve this too. Please do your part and push for the inclusion of our improvement proposal, because congestion is not going away for the long term.

p.s. At the time of writing this, the pEOS contracts work fine providing utxo transfers (using the resources we managed to get before the depletion of REX) and the wallet gets some nice usage.

ウェブサイト：https://peos.one

電報：https://t.me/pEOSone

電報中国：https://t.me/pEOS_china

ツイッター：https://twitter.com/peos_one

GitHubの：https：//でgithubの.com / peosdev

続きを読む

EOS改善提案

以下に、最初のEOS改善提案の初期バージョンを公開します。EOSIOソフトウェア開発をより分散化するために、Danの提案の後、スマートコントラクト内の楕円曲線暗号化の加速に関する改善提案の最初の記述をここに提供します。

イーサリアムの改善提案の処理方法に触発されて、EIPが最終的にEOS githubのリポジトリに統合され、誰でも貢献できるようになり、議論ができるようになります。その精神で、うまくいけば、block.oneによる改善でさえ、サードパーティの開発者がプロ​​ジェクトをより効率的に予測して貢献できるようにするために、最初にEIPとして文書化されます。

* EIP-1はどこにありますか？さて、EIP-1はEIPを行うための提案になります;）

EIP-2：楕円曲線secp256r1およびsecp256k1での加算およびスカラー乗算の組み込み関数を提供します

簡単な要約

コントラクト内の楕円曲線演算用のコンパイラツールキット組み込み関数の実装。

Abstract

This improvement proposal suggests the addition of native intrinsic functions in the EOSIO platform that expose native implementations of elliptic curve scalar multiplication and addition. The native implementation of such functions will enable a much broader spectrum of dapps to be developed on the EOSIO smart contract software platform. Such functionality should cover the natively used curve secp256r1 and additionally the curve used mainly by bitcoin and other blockchains secp256k1.

Motivation

Currently the implementation of elliptic curve operations on EOSIO has to be implemented by the smart contract itself and executed by the webassembly interpreter. Regardless of the improvements in the VM execution constantly provided by the EOSIO software updates, and even more by the anticipated EOSVM upgrade that will further improve the execution performance, elliptic curve operations can still be computationally expensive for a stack based interpreted system. EOSIO currently acknowledges that by providing native implementations for signature verification and hash generation.

Providing elliptic curve cryptography intrinsics to smart contracts will greatly improve the execution speed, along with the security that smart contract can provide to the users.

Additionally, providing primitives so basic will enable better extensibility to the system in the future without the need to provide a continuously growing native implementations of higher order functions like the signature verification that was mentioned above.

Specification

Provide the following intrinsic functions:

ecAdd_r1(r, x, y) and ecAdd_k1(r, x, y)

Inputs x, y are two curve points. Output: r is the curve point x + y where + is point addition on the elliptic curve secp256r1 in the case of ecAdd_r1 and secp256k1 in the case of ecAdd_k1. If input points do not lie on the curve or any of the coordinates is equal or larger than the field modulus p, the function asserts and the contract fails.

and:

ecMul_r1(r, x, s) and ecMul_k1(r, x, s)

Inputs (x, s) are a curve point and a scalar. Output: r is the curve point x * s, where * is the scalar multiplication on the elliptic curve secp256r1 in the case of ecMul_r1 and secp256k1 in the case of ecMul_k1. If the input point does not lie on the curve or any of the coordinates is equal or larger than the field modulus p, the function asserts and the contract fails.

Implementation

Implementation of these primitives are already available by the EOSIO software source code. Implementation should be about exposing these as intrinsic functions in the current VM and the EOSVM that will be released in the future. Exact function signatures should be designed with efficiency and code simplicity in mind.

著作

権著作権および関連する権利はCC0を介して放棄され ます。

ウェブサイト：https://peos.one

電報：https://t.me/pEOSone

電報中国：https://t.me/pEOS_china

ツイッター：https://twitter.com/peos_one

GitHubの：https：//でgithubの.com / peosdev

続きを読む

pEOS：メインネットの立ち上げ

pEOSトークンのステーキング

pEOS（PEOS）がSwitcheoに掲載されました！

pEOSQ2アップデート

EOSでプライバシー技術を有効にするためのpEOSプライバシー基金を発表

pEOSウォレットプレビュー

先週、ウォレットの実装の背後にある設計上の決定について説明した記事を発表しました。

今週の初めに、CypherglassからRobにウォレットの動作のビデオを送信しました。Robは親切にも以下のビデオでそれを提示してくれました。

https://medium.com/media/651ff4cef73199995b8d1f441670af23/href

以下のリンクをたどって、pEOSプロジェクトの詳細を確認し、コミュニティに連絡してください。

ウェブサイト：https://peos.one

電報：https://t.me/pEOSone

電報中国：https://t.me/pEOS_china

ツイッター：https://twitter.com/peos_one

GitHubの：https：//でgithubの.com / peosdev

続きを読む

連絡を取り合う