全同態加密: 簡介和使用案例

進階8/22/2024, 9:21:34 AM
本文旨在為讀者提供有關FHE可用於何種情境或設置的更高層級概述。在未來的博客文章中,我們將深入探討FHE的類型(這將影響我們可以執行的計算類型),最終我們可以找到哪種編譯器來將我們的程序翻譯為可以使用FHE計算的操作。

當人們考慮加密時,首先想到的用法是靜態加密和傳輸過程中加密。第一個允許將一些數據存儲在加密的硬碟驅動器,可行動裝置甚至雲資料庫上,並提供只有合法擁有者才能查看或編輯明文內容的保證。傳輸過程中的加密保證了通過互聯網傳輸的數據只能由其指定的接收者訪問,即使它通過公共路由器或通道傳輸。這兩種情況都依賴於加密,並具有額外的完整性保證,即數據也不會被中間的惡意攻擊者篡改。這被稱為經過身份驗證的加密:一旦數據被加密,鏈中的任何人都無法推斷出任何一位數據(機密性),也沒有人可以在不被檢測到的情況下更改密文(完整性/真實性)。

一些協作用例要求即使在密文上也允許一些非平凡的處理。這是隱私保護技術或使用中的加密的領域,完全同態加密(FHE)就是其中之一。一個例子是雲中的電子投票:例如,選民可以加密他們的選票,然後中間的某個實體會匯總所有選票以計算票數,並且只會公佈最終結果。不幸的是,使用經過身份驗證的加密,中間的實體需要解密所有選票才能執行這樣的計算,並且會看到清晰的單個選票,這非常麻煩。從理論上講,我們可以洗牌選票(一些電子投票協議實際上依賴於此),但是,與紙質選票不同,保證完整性的傳統加密機制也使得將加密選票與其發送者的身份脫鉤變得更加困難。在電子投票方案中,可以在計算選票的實體周圍添加一堵硬體牆。例如,這是可信執行飛地的目標。此類安全區將使攻擊者更難與實體進行交互。但是,硬體故障可能會洩漏解密密鑰,並且與軟體錯誤不同,硬體設計漏洞無法輕鬆修補。

為了應對這個和其他類似的使用案例,我們可以利用全同態加密(FHE)。 FHE 是一種特殊形式的加密,允許在密文上計算函數而無需解密它們,並直接獲得函數輸出的加密。

大多數情況下,要評估的函數f是公開的,因此將f(x)的加密轉換為處理步驟的序列是公開的知識,可以在雲端中進行而不涉及任何秘密。

此圖描述了三種遠程投票的情景:在最左邊的圖像中,一個可信賴的實體在發布投票結果之前對個別投票進行洗牌和解密。我們必須信任進行計算的實體,以保護選民隱私並正確計算選票。在中間的圖像中,使用可信任的執行區域提供完整性和隱私保證來執行相同的計算。在右側的圖像中,使用同態加密:加密的選票可以在結果解密之前(公開地)進行相加。E()表示加密操作,而D()表示解密。

全同态加密也是紧凑的,这意味着输出密文的比特大小和解密所需的工作量仅取决于明文结果中的比特数。它不取决于应用的计算链。这排除了简单的非紧凑加密系统,这些系统只是将x的输入密文与f的源代码简单拼接起来,让接收方通过解密x然后应用f来完成所有工作。

FHE外包通常被提出作為安全飛地的替代方案,其基礎是數學問題的困難程度,而不是實際障礙。因此,FHE對於被動側信道攻擊或雲端主機的其他損壞完全無懈可擊。想像一下,某人需要外包一些計算,但數據非常敏感。如果別人可能取得機器的root權限,這個人可能會不太願意使用雲端VM。他們可能也會猶豫是否在像SGX這樣的飛地中運行它,因為知道雲端主機的CPU和內存經常被監控以檢查負載、功率、溫度。也許一些信息可以從這些測量中提取。這個人可能會被FHE的承諾所安慰,即提取任何單一信息位都需要解決一個後量子數學問題,而與我們可能收集的任何測量無關。

如果方案提供的機密性防止攻擊者在沒有秘密金鑰的情況下讀取任何單個位元的信息,則FHE的全同態性允許攻擊者翻轉任何計算的位元:在電路中,這相當於主動側信道攻擊,攻擊者被授予了可以定位任何位元的魔法激光束。初聽起來可能很可怕,但在FHE中,這些攻擊對應於同態操作的不誠實執行。可以通過在計算中添加複製或冗余來避免這些攻擊。

FHE通常以公鑰方式呈現。這樣做有:

  1. 解密密鑰:這是加密系統的主密鑰,可以從中衍生出所有其他密鑰。解密密鑰通常在本地生成並從未傳輸,且唯一能夠解密全同態加密密文的人是解密密鑰的擁有者。
  2. 加密密鑰:在公鑰模式下,當提供初始密文的一方不是解密密鑰的擁有者時,這個中型密鑰通常由零的隨機加密組成。由於全同態加密支持仿射函數,這足以加密任何消息。
  3. 評估金鑰:這個金鑰將提供給任何將對密文進行函數評估的方。這個金鑰也可以像任何公鑰一樣安全地發佈或傳輸。評估金鑰的大小因要評估的函數是線性還是任意函數而有所不同,範圍從空到非常大。

解密金鑰擁有者是密碼系統中最敏感秘密的擁有者。這個人負責確保執行的同態操作鏈是合法的,最終密文是安全的並且可以解密,然後解密明文結果。如果在鏈中引入了惡意操作,解密金鑰可能在解密時被洩漏。幸運的是,同態操作可以在公開進行並進行驗證。

全同態加密場景

在本節中,我們描述了一些使用FHE的情境,以及每種設置的優點和缺點。

外包模式


在這個圖中,橘色的鑰匙象徵著解密鑰匙(及其擁有者)。全同態加密的密文以與解密鑰匙相同顏色的鎖來表示。貢獻私人數據的各方以圓筒表示:這裡,只有愛麗絲貢獻了私人數據。在鮑勃方面,評估函數和評估鑰匙是公開的,計算以綠色方框表示,可以被確定地進行。每個人都可以追蹤計算並檢測所宣稱的輸出密文是否不正確。

這在歷史上是首次為全同態加密發布的使用案例。它旨在將雲計算轉變為類似於安全飛地的私人計算,但基於加密安全而不是硬體安全。在這種情況下,艾麗絲擁有一些私人數據,但計算能力有限。鮑勃模擬一個計算能力更強大的雲實例。鮑勃不提供任何額外的私人數據。艾麗絲可以通過加密輸入外包一個計算,然後鮑勃對所需(公共)函數進行同態計算,並將加密結果發送回艾麗絲。

根據當前的硬件能力,外包模式在實際應用中仍然有點慢,通常可以在非線性使用情況下計算運行時間開銷因子為100萬,內存開銷為1000。然而,目前正在開發FHE硬件以彌補差距,例如Gate。Darpa DPRIVE 项目或者加密之光.

目前,在實踐中,外包模式被用於 PIR(私人信息檢索)用例,其中服務器(Bob)擁有一個大型公共數據庫,客戶端(Alice)發出查詢,被查詢的索引應保持私密。這樣的 PIR 方案從同態加密操作的線性和緊湊性中受益良多,而電路的小乘法深度保持計算成本在合理範圍內。

這張表彙總了外包模式的利與弊。

雙方計算模式

這個圖使用與先前相同的顏色編碼。這一次,Bob 用一些私人數據參與計算。Bob 端的計算不再是公開可驗證的,用一個紅色框表示,這種模式應該限制在誠實但好奇的使用情況。

在這個新的設置中,唯一的區別是 Bob 用一些私人數據參與計算。在這種情況下,全同態加密是一種良好的雙方計算解決方案,通信最小,對查詢方提供強有力的保證:Bob 不知道 Alice 的數據,而 Alice 知道計算的結果。

在這種情況下的一個潛在應用是百萬富翁問題,Alice 和 Bob 是兩位百萬富翁,他們想要知道誰更富有,而不向對方透露自己的財富。這個問題的解決方案被應用在電子商務應用中。

聚合模式

這是對外包模式的一種改進,其中來自許多參與者的數據可以以緊湊的方式(即輸出不隨參與者數量增加而增加)並且可以公開驗證地聚合。典型用途包括聯合學習和電子投票。

客戶端-服務器模式

這個設置是兩方計算模式的改進,其中計算方現在為多個客戶提供安全的計算服務,這些客戶都有自己的秘密金鑰。例如,FHE可以用作私有模型預測服務(例如具有私有模型和輸入的 ML 服務):伺服器擁有私有模型(明文形式的私有模型),每個客戶都有自己的數據,並希望運行預測。因此,每個客戶檢索自己的加密預測,並使用自己的秘密金鑰。

同態加密如何確保所計算的函數是合法的?

在協作場景中使用 FHE 總是更容易,其中每個參與者都有誠實遵循協議的動機。例如,FHE 可用於計算兩個不同國家/地區同一集團的兩個法人實體之間的統計數據:GDPR 等法規允許發佈一些統計數據,但通常禁止在同一地點收集所有個人數據。在這種情況下,使用FHE是可能的,所有參與者都有動力誠實地遵循協定。在非協作方案中,確保已計算相關函數的最簡單方法是引入冗餘。例如,在外包和聚合場景中,同態計算是完全公開的,可以確定。只要兩個或多個獨立的實體最終具有完全相同的輸出密文,那麼計算是正確的,結果可以安全地解密。冗餘越多,我們對結果的信心就越高,這當然是與效率的權衡。

此外,當計算方通過數字簽名輸入和輸出密文背書FHE結果時,每個人都可以重新追溯相同的FHE計算並檢查證明是否有效。 FHE計算方的任何作弊企圖都可以被公開捕捉,并與公開可驗證的證書關聯起來,揭示作弊和作弊者 - 我們稱之為強隱蔽安全模型。

全同态签名是另一種驗證計算正確性的方法,無需獨立驗證器,但通常需要更多的資源。

全同态加密如何确保最终接收者仅解密最终结果而不解密中间变量?

最簡單的方法是確保解密金鑰擁有者無法訪問任何中間密文。

在雙方情況下,或者在客戶端-伺服器情況下,Alice對輸入進行加密,Bob對密文進行計算,然後將加密輸出返回給Alice,很明顯Alice只能解密結果,她無法訪問其他任何變量。

在雲聚合場景中,比如電子投票,眾多參與者在共同雲上發送加密的選票,另一種技術被使用:解密金鑰通常不會給予單一接收者,而是秘密分享給解密機構的不同成員。在這種情況下,只能通過執行多方計算來觸發對特定密文的解密,這涉及解密機構成員之間的在線通信。如果一個成員拒絕解密密文,則無法進行解密。這確保只有所有解密機構成員都同意的密文才能被解密。

同态加密的基本构建模块

全同態加密有三種:部分同態加密(PHE)、層次同態加密(LHE)和全同態加密(FHE)。部分同態加密只允許我們計算一個受限制的函數集(例如,只有加法,只有線性函數,只有雙線性函數),而層次和全同態加密可以評估任意電路,或者等效地說,控制流程與數據無關的函數。對於LHE,密碼參數取決於函數並隨電路的複雜性增長,這導致更大的密文和密鑰。對於給定的參數集,FHE方案允許我們評估可以表示為具有算術或二進制閘的電路的任何函數,因此,與LHE相比,即使要評估的電路越來越大,方案的參數(以及密鑰和密文)也不會變得更大。

換句話說,當被問到給定的明文電路是否可以同態運行,以及成本(時間和記憶體開銷)時,PHE可能會回答“否”。LHE的回答是肯定的,但可能會為複雜電路設定任意的高成本。FHE 的答案也是肯定的,此外,它還提供了密鑰、加密和解密演演演算法,以及如何在指定明文電路之前同態評估一組通用門。因此,FHE 是唯一保證同態評估的記憶體和運行時間與原始明文電路成比例的模式。為此,目前已知的所有 FHE 方案都處理嘈雜的密文,隨著計算的完成,這些密文變得越來越嘈雜。為了避免雜訊溢出到完成的計算中並導致解密錯誤,這些方案定期執行稱為自舉的相當昂貴的操作,從而將雜訊降低到可管理的水準。有關每種方案的細節、引導以及如何使用 FHE 編譯器最小化雜訊和其他成本的更多資訊,請參閱本系列的第二篇博客文章!

免責聲明:

  1. 本文轉載自[cryptographycaffe], 所有版權屬於原作者 [ Nicolas Gama和Sandra Guasch]。如果對此轉載有異議,請聯繫Gate 學習團隊將會迅速處理。
  2. 責任免責聲明:本文觀點僅代表作者個人意見,並不構成任何投資建議。
  3. 本文的翻譯由 Gate Learn 團隊完成。未經許可,禁止複製、分發或剽竊翻譯後的文章。

全同態加密: 簡介和使用案例

進階8/22/2024, 9:21:34 AM
本文旨在為讀者提供有關FHE可用於何種情境或設置的更高層級概述。在未來的博客文章中,我們將深入探討FHE的類型(這將影響我們可以執行的計算類型),最終我們可以找到哪種編譯器來將我們的程序翻譯為可以使用FHE計算的操作。

當人們考慮加密時,首先想到的用法是靜態加密和傳輸過程中加密。第一個允許將一些數據存儲在加密的硬碟驅動器,可行動裝置甚至雲資料庫上,並提供只有合法擁有者才能查看或編輯明文內容的保證。傳輸過程中的加密保證了通過互聯網傳輸的數據只能由其指定的接收者訪問,即使它通過公共路由器或通道傳輸。這兩種情況都依賴於加密,並具有額外的完整性保證,即數據也不會被中間的惡意攻擊者篡改。這被稱為經過身份驗證的加密:一旦數據被加密,鏈中的任何人都無法推斷出任何一位數據(機密性),也沒有人可以在不被檢測到的情況下更改密文(完整性/真實性)。

一些協作用例要求即使在密文上也允許一些非平凡的處理。這是隱私保護技術或使用中的加密的領域,完全同態加密(FHE)就是其中之一。一個例子是雲中的電子投票:例如,選民可以加密他們的選票,然後中間的某個實體會匯總所有選票以計算票數,並且只會公佈最終結果。不幸的是,使用經過身份驗證的加密,中間的實體需要解密所有選票才能執行這樣的計算,並且會看到清晰的單個選票,這非常麻煩。從理論上講,我們可以洗牌選票(一些電子投票協議實際上依賴於此),但是,與紙質選票不同,保證完整性的傳統加密機制也使得將加密選票與其發送者的身份脫鉤變得更加困難。在電子投票方案中,可以在計算選票的實體周圍添加一堵硬體牆。例如,這是可信執行飛地的目標。此類安全區將使攻擊者更難與實體進行交互。但是,硬體故障可能會洩漏解密密鑰,並且與軟體錯誤不同,硬體設計漏洞無法輕鬆修補。

為了應對這個和其他類似的使用案例,我們可以利用全同態加密(FHE)。 FHE 是一種特殊形式的加密,允許在密文上計算函數而無需解密它們,並直接獲得函數輸出的加密。

大多數情況下,要評估的函數f是公開的,因此將f(x)的加密轉換為處理步驟的序列是公開的知識,可以在雲端中進行而不涉及任何秘密。

此圖描述了三種遠程投票的情景:在最左邊的圖像中,一個可信賴的實體在發布投票結果之前對個別投票進行洗牌和解密。我們必須信任進行計算的實體,以保護選民隱私並正確計算選票。在中間的圖像中,使用可信任的執行區域提供完整性和隱私保證來執行相同的計算。在右側的圖像中,使用同態加密:加密的選票可以在結果解密之前(公開地)進行相加。E()表示加密操作,而D()表示解密。

全同态加密也是紧凑的,这意味着输出密文的比特大小和解密所需的工作量仅取决于明文结果中的比特数。它不取决于应用的计算链。这排除了简单的非紧凑加密系统,这些系统只是将x的输入密文与f的源代码简单拼接起来,让接收方通过解密x然后应用f来完成所有工作。

FHE外包通常被提出作為安全飛地的替代方案,其基礎是數學問題的困難程度,而不是實際障礙。因此,FHE對於被動側信道攻擊或雲端主機的其他損壞完全無懈可擊。想像一下,某人需要外包一些計算,但數據非常敏感。如果別人可能取得機器的root權限,這個人可能會不太願意使用雲端VM。他們可能也會猶豫是否在像SGX這樣的飛地中運行它,因為知道雲端主機的CPU和內存經常被監控以檢查負載、功率、溫度。也許一些信息可以從這些測量中提取。這個人可能會被FHE的承諾所安慰,即提取任何單一信息位都需要解決一個後量子數學問題,而與我們可能收集的任何測量無關。

如果方案提供的機密性防止攻擊者在沒有秘密金鑰的情況下讀取任何單個位元的信息,則FHE的全同態性允許攻擊者翻轉任何計算的位元:在電路中,這相當於主動側信道攻擊,攻擊者被授予了可以定位任何位元的魔法激光束。初聽起來可能很可怕,但在FHE中,這些攻擊對應於同態操作的不誠實執行。可以通過在計算中添加複製或冗余來避免這些攻擊。

FHE通常以公鑰方式呈現。這樣做有:

  1. 解密密鑰:這是加密系統的主密鑰,可以從中衍生出所有其他密鑰。解密密鑰通常在本地生成並從未傳輸,且唯一能夠解密全同態加密密文的人是解密密鑰的擁有者。
  2. 加密密鑰:在公鑰模式下,當提供初始密文的一方不是解密密鑰的擁有者時,這個中型密鑰通常由零的隨機加密組成。由於全同態加密支持仿射函數,這足以加密任何消息。
  3. 評估金鑰:這個金鑰將提供給任何將對密文進行函數評估的方。這個金鑰也可以像任何公鑰一樣安全地發佈或傳輸。評估金鑰的大小因要評估的函數是線性還是任意函數而有所不同,範圍從空到非常大。

解密金鑰擁有者是密碼系統中最敏感秘密的擁有者。這個人負責確保執行的同態操作鏈是合法的,最終密文是安全的並且可以解密,然後解密明文結果。如果在鏈中引入了惡意操作,解密金鑰可能在解密時被洩漏。幸運的是,同態操作可以在公開進行並進行驗證。

全同態加密場景

在本節中,我們描述了一些使用FHE的情境,以及每種設置的優點和缺點。

外包模式


在這個圖中,橘色的鑰匙象徵著解密鑰匙(及其擁有者)。全同態加密的密文以與解密鑰匙相同顏色的鎖來表示。貢獻私人數據的各方以圓筒表示:這裡,只有愛麗絲貢獻了私人數據。在鮑勃方面,評估函數和評估鑰匙是公開的,計算以綠色方框表示,可以被確定地進行。每個人都可以追蹤計算並檢測所宣稱的輸出密文是否不正確。

這在歷史上是首次為全同態加密發布的使用案例。它旨在將雲計算轉變為類似於安全飛地的私人計算,但基於加密安全而不是硬體安全。在這種情況下,艾麗絲擁有一些私人數據,但計算能力有限。鮑勃模擬一個計算能力更強大的雲實例。鮑勃不提供任何額外的私人數據。艾麗絲可以通過加密輸入外包一個計算,然後鮑勃對所需(公共)函數進行同態計算,並將加密結果發送回艾麗絲。

根據當前的硬件能力,外包模式在實際應用中仍然有點慢,通常可以在非線性使用情況下計算運行時間開銷因子為100萬,內存開銷為1000。然而,目前正在開發FHE硬件以彌補差距,例如Gate。Darpa DPRIVE 项目或者加密之光.

目前,在實踐中,外包模式被用於 PIR(私人信息檢索)用例,其中服務器(Bob)擁有一個大型公共數據庫,客戶端(Alice)發出查詢,被查詢的索引應保持私密。這樣的 PIR 方案從同態加密操作的線性和緊湊性中受益良多,而電路的小乘法深度保持計算成本在合理範圍內。

這張表彙總了外包模式的利與弊。

雙方計算模式

這個圖使用與先前相同的顏色編碼。這一次,Bob 用一些私人數據參與計算。Bob 端的計算不再是公開可驗證的,用一個紅色框表示,這種模式應該限制在誠實但好奇的使用情況。

在這個新的設置中,唯一的區別是 Bob 用一些私人數據參與計算。在這種情況下,全同態加密是一種良好的雙方計算解決方案,通信最小,對查詢方提供強有力的保證:Bob 不知道 Alice 的數據,而 Alice 知道計算的結果。

在這種情況下的一個潛在應用是百萬富翁問題,Alice 和 Bob 是兩位百萬富翁,他們想要知道誰更富有,而不向對方透露自己的財富。這個問題的解決方案被應用在電子商務應用中。

聚合模式

這是對外包模式的一種改進,其中來自許多參與者的數據可以以緊湊的方式(即輸出不隨參與者數量增加而增加)並且可以公開驗證地聚合。典型用途包括聯合學習和電子投票。

客戶端-服務器模式

這個設置是兩方計算模式的改進,其中計算方現在為多個客戶提供安全的計算服務,這些客戶都有自己的秘密金鑰。例如,FHE可以用作私有模型預測服務(例如具有私有模型和輸入的 ML 服務):伺服器擁有私有模型(明文形式的私有模型),每個客戶都有自己的數據,並希望運行預測。因此,每個客戶檢索自己的加密預測,並使用自己的秘密金鑰。

同態加密如何確保所計算的函數是合法的?

在協作場景中使用 FHE 總是更容易,其中每個參與者都有誠實遵循協議的動機。例如,FHE 可用於計算兩個不同國家/地區同一集團的兩個法人實體之間的統計數據:GDPR 等法規允許發佈一些統計數據,但通常禁止在同一地點收集所有個人數據。在這種情況下,使用FHE是可能的,所有參與者都有動力誠實地遵循協定。在非協作方案中,確保已計算相關函數的最簡單方法是引入冗餘。例如,在外包和聚合場景中,同態計算是完全公開的,可以確定。只要兩個或多個獨立的實體最終具有完全相同的輸出密文,那麼計算是正確的,結果可以安全地解密。冗餘越多,我們對結果的信心就越高,這當然是與效率的權衡。

此外,當計算方通過數字簽名輸入和輸出密文背書FHE結果時,每個人都可以重新追溯相同的FHE計算並檢查證明是否有效。 FHE計算方的任何作弊企圖都可以被公開捕捉,并與公開可驗證的證書關聯起來,揭示作弊和作弊者 - 我們稱之為強隱蔽安全模型。

全同态签名是另一種驗證計算正確性的方法,無需獨立驗證器,但通常需要更多的資源。

全同态加密如何确保最终接收者仅解密最终结果而不解密中间变量?

最簡單的方法是確保解密金鑰擁有者無法訪問任何中間密文。

在雙方情況下,或者在客戶端-伺服器情況下,Alice對輸入進行加密,Bob對密文進行計算,然後將加密輸出返回給Alice,很明顯Alice只能解密結果,她無法訪問其他任何變量。

在雲聚合場景中,比如電子投票,眾多參與者在共同雲上發送加密的選票,另一種技術被使用:解密金鑰通常不會給予單一接收者,而是秘密分享給解密機構的不同成員。在這種情況下,只能通過執行多方計算來觸發對特定密文的解密,這涉及解密機構成員之間的在線通信。如果一個成員拒絕解密密文,則無法進行解密。這確保只有所有解密機構成員都同意的密文才能被解密。

同态加密的基本构建模块

全同態加密有三種:部分同態加密(PHE)、層次同態加密(LHE)和全同態加密(FHE)。部分同態加密只允許我們計算一個受限制的函數集(例如,只有加法,只有線性函數,只有雙線性函數),而層次和全同態加密可以評估任意電路,或者等效地說,控制流程與數據無關的函數。對於LHE,密碼參數取決於函數並隨電路的複雜性增長,這導致更大的密文和密鑰。對於給定的參數集,FHE方案允許我們評估可以表示為具有算術或二進制閘的電路的任何函數,因此,與LHE相比,即使要評估的電路越來越大,方案的參數(以及密鑰和密文)也不會變得更大。

換句話說,當被問到給定的明文電路是否可以同態運行,以及成本(時間和記憶體開銷)時,PHE可能會回答“否”。LHE的回答是肯定的,但可能會為複雜電路設定任意的高成本。FHE 的答案也是肯定的,此外,它還提供了密鑰、加密和解密演演演算法,以及如何在指定明文電路之前同態評估一組通用門。因此,FHE 是唯一保證同態評估的記憶體和運行時間與原始明文電路成比例的模式。為此,目前已知的所有 FHE 方案都處理嘈雜的密文,隨著計算的完成,這些密文變得越來越嘈雜。為了避免雜訊溢出到完成的計算中並導致解密錯誤,這些方案定期執行稱為自舉的相當昂貴的操作,從而將雜訊降低到可管理的水準。有關每種方案的細節、引導以及如何使用 FHE 編譯器最小化雜訊和其他成本的更多資訊,請參閱本系列的第二篇博客文章!

免責聲明:

  1. 本文轉載自[cryptographycaffe], 所有版權屬於原作者 [ Nicolas Gama和Sandra Guasch]。如果對此轉載有異議,請聯繫Gate 學習團隊將會迅速處理。
  2. 責任免責聲明:本文觀點僅代表作者個人意見,並不構成任何投資建議。
  3. 本文的翻譯由 Gate Learn 團隊完成。未經許可,禁止複製、分發或剽竊翻譯後的文章。
Comece agora
Registe-se e ganhe um cupão de
100 USD
!
It seems that you are attempting to access our services from a Restricted Location where Gate.io is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Thailand, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.