大咖專訪：Conflux公鏈研究總監「楊光」現場解決實際技術問題

第一個問題是關於 Conflux 的

The first question about Conflux is:

Conflux 實驗室環境的 TPS 峯值是 6000

Conflux can reach 6000 TPS under the testing environment,

如今說的是3000

but 3000 TPS is being said, then

具體是哪一個數據爲準

which of the two TPS-Numbers is more precise?

6000 多和 3000 的實驗的測試環境是不同的

The testing environments for 6000 and 3000 TPS are not the same!

6000 TPS的測試環境中

For the 6000 TPS testing environment,

每一個節點的帶寬是 40 Mbps

each node has a bandwidth of 40 Mbps

3000 的對應的是 20 Mbps

And for the 3000 TPS the bandwidth for each node is 20 Mbps.

可是由於咱們認爲實踐中可能 40 Mbps

But we think that 40 Mbps bandwidth per node

相對來講是比較難達到的

are quite hard to realize in practice.

以如今的網絡條件

And with the current network conditions

因此通常咱們以 3000 TPS爲準

we use 3000 TPS as our standard.

Conflux 可達到 4000—6000 的 TPS

Conflux can reach 4000 - 6000 TPS

區塊確認時間爲 4.5—7.4 分鐘

With a block confirmation time of 4.5 - 7.4 minutes.

有聲音認爲正常的確認時間若是不出現分叉

Some might think that if there are no forks in the confirmation time

則必然會丟棄大量的有效交易

a large number of valid transactions will be discarded.

在這麼長的延遲時間下談高 TPS

Talking about high TPS with such a long delay

沒有實際的應用價值

has no value for potential real-life applications.

首先丟棄大量有效交易

Discarding large amounts of valid transaction

這個是在比特幣

Is something that can only be found in Bitcoin

或者其它採用最長鏈規則的區塊鏈裏面纔會有的

or other public chains that use the Longest-Chain Rule.

可是咱們會保留全部分叉的區塊

But we keep all forked blocks

因此全部的交易都不會丟失

And therefore, all transactions stay and don’t disappear.

而後其次

ANd,

關於確認時間比較慢的問題

About the slow confirmation time!

這個用的數據是咱們比較早的實驗數據

The number is from our initial tests,

在當時咱們採用了很是保守的五秒鐘一個塊

where we used a conservative average time of 5 seconds per block

因此確認時間是大概 4 分鐘到 7 分鐘左右

That resulted in a block confirmation time between 4 and 7 minutes.

可是如今咱們在測試網上新的結果

But now on our test net,

是每秒鐘出四個塊

We can produce 4 blocks per second

就是出塊的速度提升到 20 倍

Resulting in a time increase of 20 times

而後確認時間也能夠縮短到 30 秒之內

And the block confirmation time can be shortened to under 30 seconds.

但這個仍是關於區塊的確認時間

But this is only about the block confirmation time.

實際上若是說咱們考慮單筆交易的確認時間

If we consider the confirmation time of a single transaction in reality,

只要咱們在相對一段時間內分叉的區塊中

as long as we don’t find any conflicts of this one transaction

都沒有和這個交易衝突的任何其它交易

with other transactions in forked blocks from a certain time period, 

那麼即便這個區塊的順序有必定的變化

even if the sequencing of this block has some changes,

但這樣一筆簡單的交易

such a simple transaction

依然沒有任何 衝突

will have no conflicts

依然會是有效的

and will be valid.

這種狀況下咱們通過分析

We have analyzed such a situation

其實還能夠把確認時間再進一步的縮短

And can even shorten the confirmation time.

但這個須要就更復雜的分析之後

But this needs more complex analysis

才能夠肯定到底能到多短

To confirm to which extend the confirmation time can be reduced.

加密算法的抗衝突性如何

How is the collision resistance of the encryption algorithm?

加密算法的抗衝突性

The collision resistance of the encryption algorithm

並非加密算法的設計指標之一

is not actually one of the design indicators for the encryption algorithm.

因此有一些算法可能會有抗衝突性

Therefore, only some algorithms might be able to achieve collision resistance,

可是這個並無廣泛的要求

but this has special needs!

好比說咱們熟悉的一次一密的加密算法

For example, with the one-time pad algorithm

包括 AES 這樣的加密算法

and even when we encrypt the algorithm, with let’s say AES, 

都是對衝突性沒有任何抵抗能力的

the algorithm is not really resistant to conflict.

咱們隨便的就能夠找到一個明文和密鑰對

We can find a random plain text and pair it with a key

生成任何的一個密文

and form any encryption.

可是在有些場景下

But in some scenarios,

若是咱們須要對加密的明文的完整性進行檢驗

if we need to do an integrity test on the completeness of the encrypted plain text

咱們一般會用到一種叫作認證加密的算法

an algorithm called authentication encryption (AE) is usually used.

這個會比普通的加密算法要稍微複雜一點

This is a bit more complicated than normal encryption.

但基本的原理就是除了明文信息之外

The basics are: besides the plain text

我還要附帶上一個明文消息的哈希值

we need to attach the hash of the plain text

而後把明文消息和哈希值放在一塊兒進行加密

and then encrypt the plain text with the respective hash.

這樣解密的時候

Like this, during the decryption process,

若是用不一樣的密鑰解出來的

when using a non-corresponding key to decrypt

就不會在原來的明文的空間裏邊

the decrypted message will be totally different

由於解出來之後

because the hash of the decrypted plain text

對應的哈希值是對不上的

does not match the corresponding hash value.

因此這種狀況下

So in this situation,

就能夠保證很難找到一個衝突

finding a conflict of single transactions will be very hard.

這裏抗衝突性仍是經過哈希函數實現的

The collision resistance is realized the hash function

而不是經過加密算法自己

and not the encryption algorithm.

爲何一個好的哈希算法

So why does a good hash-algorithm

不容許攻擊者找到兩個產生相同哈希的消息

not allow the attacker to find two produced messages with the same hash function?

首先這個是密碼學哈希算法的定義所要求的

This is the first requirement in Cryptography for hash algorithms

這也是密碼學哈希算法最主要的目的

And is also the most important purpose of hash algorithms.

而後他們要作的就是讓生成的哈希的結果

And then they need to ensure that the result of the generated hash

是很是難預測的

is very hard to predict.

由於難以預測

Because it is hard to predict

並且是不可逆的

and is irreversible due to it being asymmetric

因此就很難讓攻擊者找到兩個不一樣的明文

it is very hard for the attacker to find two different plain texts

對應一樣的哈希值

with the same hash value.

這樣的話就能夠把哈希值做爲明文的一個表明

This way we can see the hash value being a representative of the plain text

而後去使用

and using it

會比較方便

will be easier.

如何將 AES 加密中使用的密鑰

How to share a key with AES encryption 

與其它應用程序共享進行解密

with other applications for decryption?

這個共享的方式是有不少

There are many ways to share

固然最簡單的共享方式是你把這個密鑰

The easiest way to share is for you to copy

抄下來或者拷貝下來

or write down the key

而後以一個安全的方式傳輸給對方

and then use a safe method to send it to the opposite party.

這個安全的方式能夠是一個已經加密的信道

This ‘safe method’ can be an already encrypted messaging channel

或者也能夠是人線下

or offline

就是人肉去傳輸

meaning giving it to someone in person.

固然在線上傳輸的話

Of course, if it is transmitted online

能夠用一些密碼學

cryptography can be used.

主要是公鑰密碼學裏

In Public-Key cryptography,

會有專門的密鑰交換協議

there are so-called key exchange protocols.

用這樣的協議你們就能夠

These protocols allow multiple parties

在線上去產生一個雙方共享的密鑰

to generate a shared key by exchanging messages.

同時即使中間被人竊聽

Furthermore, even if an eavesdropper 

大家交換的消息

has access to all the exchanged messages,

 這個密鑰依然是安全的

the generated key remains secure (against the eavesdropper).