密碼學在區塊鏈隱私保護中的應用學習

身份隱私保護技術

混淆服務

  • 混淆服務的目的在于混淆消息雙方的聯系(如 圖 2 所示)。當發送方需要告知接收方消息 M 時, 它會首先用接收方的公鑰 KB 加密 M,并在密文后 附帶真實接收地址 R。為了借助第三方(圖 2 中的 混淆服務器)的能力隱藏交易雙方的關聯性,發送 方會繼續用第三方的公鑰 KI 做第二重加密,并將結果(見下方公式的箭頭左側)提交給第三方。

  • 當第三方接收到若干密文后,分別進行解密以獲取原始密文,并根據解密出來的地址進行轉發 ; 接收方收到消息后可自行解密獲知消息 M。整個過程用加密方式保證接收方地址不可見,用雙重隨機數保證每次會話之間不可鏈接。當第三方處理的交易達到一定數量時,可以有效實現消息來源與目的地之間關系的混淆。
  • 這種方式部署簡單,且與區塊鏈有很好的兼容性,因此得到廣泛采用。現有的研究進展主要集中在中心化混淆和分布式混淆兩個方面。

中心化混淆

  • 中心化混淆是指混淆服務由單一實體提供,例 如單個服務器、企業等。
  • 目前有多家網站提供有償 混淆服務,例如 Onionbc、Bitcoin Fog、Bitmixer 等。 他們可以有效隱藏交易地址,但是存在一定的缺陷: (1) 服務提供商本身是潛在的攻擊者,存在支付抵賴等欺詐風險 ;(2) 處于中間位置的混淆服務提供商有機會知道并記錄交易雙方的信息。

第一個問題的解決措施

  • 針對第一個問題,即交易的公平性。
  • 條件執行是可行的方式之一。它設定當且僅當混淆服務商誠實執行混淆服務后,才可以獲得服務費,否則什么都得不到。格雷戈里·麥克斯韋 (Gregory Maxwell) 為比特幣設計了 CoinSwap 協議 ,允許交易發起者設定哈希鎖關聯到特定的贖回腳本,防止數字資產被竊取。
  • 另一種解決方法是可信審計,即混淆服務器留下可信憑證,若出現違規行為則可以進行有效追責。例如 Mixcoin基于簽名機制保證審計過程的不可抵賴性。
  • 2015 年發布的達世幣 (Dash) 嘗 試從經濟學角度解決中心化混淆方案面臨的隱私泄 露問題。該方案中,混淆節點負責匯集并生成混淆 方案,通過預付保證金的方式提高違規代價。
  • 然而, 這幾種方案中混淆服務器仍掌握著交易地址間的關聯信息

第二個問題的解決措施

  • 盲簽名是解決第二個問題的有效方法之一,一 般包括 3 個階段 :盲化(使用隨機盲化因子隱藏消息),簽名(簽名者對盲化后的消息做簽名),去盲化(去掉盲化因子,提取出對消息的有效簽名)。此類簽名的特點是待簽名的消息對簽名者不可見。因 此,Blindcoin[4] 將盲簽名的思想引入 Mixcoin 中, 既可提供對不當行為的審計憑證,又可以保證混淆 服務器無法分辨所簽交易接收方的地址是哪個,從而保證地址信息的隱私性。然而,這種機制要求交易金額必須是固定的,且這種方案無法避免混幣節 點的違規行為。
  • TumbleBit[5] 首次同時實現了交易不可鏈接性 和防資產盜竊。它的思路是利用安全兩方計算來 保證用戶隱私和交易公平性,主要包括 3 個步驟 : (1) Puzzle-Promise 階段,接收方與混淆服務器建立 托管交易,加密贖回腳本,并將密文盲化后轉交給 發送方。(2) 發送方與混淆服務器執行安全兩方計算完成解密。在該過程中,發送方會采用條件交易的方式保證雙方的公平性。(3) 接收方將答案去盲化, 贖回托管交易。

問題

  • 上述中心化的混淆方案具有易操作性,但是普遍存在 3 個弊端 :(1) 時延較長,需等待足夠多的混 淆請求者,以保證混淆效果 ;(2) 集中式的混淆服務器易遭受拒絕服務 (DoS) 攻擊 ;(3) 實際應用中需要支付額外的混淆費用。

分布式混淆

  • 為了減輕因集中式構架帶來的單點威脅,同時節約混淆成本,研究人員開始思考分布式的交易混淆模式,即由多個互相不完全信任的對等實體共同執行匿名交易發布,而無需第三方代理。
  • 目前主流 的解決方法有 CoinJoin[6] 和安全多方計算 (MPC)。
  • CoinJoin[6] 的核心思想是“尋找志同道合者一 起交易”。圖 3 可以直觀地解釋 CoinJoin 的思路。

  • 現有由兩筆交易 A → C 和 B → D 待支付(圖 3 左 側),CoinJoin 將這兩筆交易揉在一起形成一筆 2 輸 入、4 輸出的交易,外部觀察者是無法分辨出這兩筆交易的。CoinJoin 因其與比特幣的高度兼容性(僅 需利用修改比特幣協議的多重簽名機制),提出之后很快被應用于工程上,例如 Dark Wallet、Joinmarket 等。 但是 CoinJoin 機制還留有 3 個值得改進的地方 : 1. 缺乏內部不可鏈接性。以圖 3 為例,參與者 A 和 C 是明確知道對方交易信息的。隨著參與者數量增多,遭受 Sybil 攻擊的可能性也會提高(即某參與者是惡意攻擊者假扮的)。 2. 易受 DoS 攻擊。此類 DoS 攻擊是指攻擊者 通過拒絕簽署贖回腳本,導致整個交易無法贖回, 由于比特幣交易不可撤銷,這種攻擊很可能會造成嚴重的資產損失。 3. 從實用的角度來講,CoinJoin 受制于參與者人數,若人數過少,則無法達到匿名性要求 ;若人數過多,則通信開銷呈指數級增長,且提高了被 DoS 攻擊的風險。 隨后的方案針對這三個問題進行了改進 :Coin- Shuffle[7] 采用層層加密和隨機置換的方式洗牌輸出 地址,即便是參與者也不知道交易地址間的關聯性。 但是,這種方案以高通信和計算成本為代價,同時 對因攻擊者拒絕簽署贖回腳本而造成損失的狀況仍 束手無策。
  • 安全多方計算指的是參與者在無須歸集私有數據的情況下完成協同計算,同時保護各數據所有方的原始數據隱私。CoinParty[8] 就是基于安全多方計 算優化分布式混淆過程的一種改進協議,設定交易 的贖回腳本須參與方執行門限簽名, 容忍一定數量節點的失效或惡意操作, 可以有效對抗 Sybil 或 DoS 攻擊。

環簽名

  • 分布式混淆機制需要等待其他參與者一起執行混淆協議,這個過程取決于何時找到具有共同交易意愿的人, 因此等待時延難以預計。而環簽名機制,允許用戶在無需其他“環”成員 在線的情況下,自行簽名,且關于公鑰的信息隱藏于整個“環”中,有效保障了簽名的身份隱私需求。

原理解釋

  • 一般環簽名的思路如下圖所示,假定“環”中有n 個成員(各自擁有一對公私鑰),簽名者 A 使 用公鑰集合{pk1, …, pkn}和自己的私鑰ski產生簽名。 這個簽名的某個參數根據一定規則呈環狀,環簽名 由此得名。驗證者只能夠驗證簽名結果的合法性, 但無法確定真正的簽名者。通過此方法,簽名者可 以自由指定自己的匿名范圍,并且無須等待環成員在線,可以提供非常優美的匿名性保護。
  • 可鏈接環簽名是環簽名的一個變種,設計初期是為了滿足同一個簽名者簽相同消息時的追責需求,例如匿名投票。在環簽名的基礎結構之上,每 個簽名還附帶有標簽 T=(issue, PK),其中 PK 表示圖 4 的環成員公鑰集合,issue 是選票的標簽。

  • 驗證者使用 T=(issue, PK) 而非 PK 來驗證環簽名,此時可以保證 : 1. 由不同的標簽 T 產生的任何簽名都是不可鏈接的 ;2. 用相同的 T 簽兩個不同的消息,可以及時被發現(即可鏈接性),但仍可隱藏真實身份。

CryptoNote 和 Monero

  • 區塊鏈有防雙重支付的需求,因此若想使用環簽名保護簽名者的身份隱私,就需要采用可鏈接環簽名的思路(見圖 5)。在 CryptoNote[9] 中,簽名者 使用一次性私鑰生成密鑰鏡像,作為 T 中的 issue附在交易贖回腳本中。若同一交易贖回兩次,則可 以被及時發現并判定無效。

  • 除了使用可鏈接環簽名保證發送方的身份隱私外,CryptoNote 在接收端設定每筆交易僅使用一次 性公私鑰對(如圖 6 所示的一次性支付 (one-time payment) 機制),即交易的輸出目的地址是一個僅可以由發送方和接收方生成的公鑰地址,該地址中 包含有隨機數,交易贖回后即丟棄,保證交易目標地址不會重復。 但 CryptoNote 明文形式的交易金額會削弱匿名性效果。因此,2014 年公布的 Monero 幣借鑒 CryptoNote 的思想,結合可鏈接自發匿名環簽名 (MLSAG) 和機密交易 (Confidential Transaction, CT), 設計環上的機密交易 RingCT[10],把交易金額隱藏在同態密文之后,同時實現了身份隱私和交易隱私。

非交互式零知識證明

  • 非交互式零知識證明 (Non-Interactive Zero- Knowledge proof, NIZK) 是零知識證明的一種,支持 證明者在不提供任何有用信息的情況下,向驗證者 證明某論斷。這個過程不需要雙方同時在線交互, 因此非常適合應用于區塊鏈中進行匿名的消息驗證。

原理解釋

  • 一般的 NIZK 形式化定義為 :假定概率多項 式時間算法 (P, V) 分別代表證明者和驗證者,那么 對于任意安全參數為 k 的描述 ??NP,若 (P, V) 是 NIZK 系統,則需滿足以下 3 個性質 :

正確性

  • 對于任意 x∈? 及其特定證據 w, 滿足如下的公式所示,即若 P 知道論斷 x 的證據 w,則一定能通過有 效算法使 V 相信它。

完備性

  • 對于任意 x?? 和概率多項式算法 P*,滿足如下的公式,即若 x 是錯誤論斷,則一定不存在有效算法使 V 相信它

零知識性

  • 對于任意 x ∈ ? 和特定證明 w, 存在概率多項式時間模擬器 S 使得以下兩組分布計 算不可區分 :

  • 即驗證者看到的信息也可以通過一個概率多項 式時間模擬器來模擬,驗證者沒有獲得任何額外信 息。描述中 p(·) 代表多項式,R 代表 NIZK 系統中 的公共參考串 (Common Reference String, CRS)。

Zerocoin 和 Zerocash

  • Zerocoin首次將 NIZK 應用于區塊鏈,讓區塊鏈節點在不知道具體交易內容的情況下驗證交易的有效性,既保留區塊鏈互相不信任的個體間的共 識達成問題,又可以保護用戶隱私。其主要思想類 似于分布式混淆機制,交易前首先熔鑄一個數字貨 幣,然后用一個等價的全新數字貨幣兌換,其中熔 鑄數字貨幣的真實性和有效性由 NIZK 系統來驗證。 具體過程可以形式化為“熔鑄→公布→兌換” 三個步驟。
  • 例如 :A 打算向 B 支付一個數字貨幣。 首先,A 計算隨機序列號 sn,用陷門 r 對它做承諾, 得到 cm(該承諾值僅可以通過 (sn, r) 來打開,但無 法計算出 (sn, r))。然后,A 發布帶有 cm 的熔鑄交易, 區塊鏈節點對執行共識算法進行驗證和記錄。B 在 做數字貨幣兌換時需要提供關于如下論斷的零知識 證明 π :1, 公共賬本中有某個特定的承諾 cm ; 2, B 知道該承諾對應的陷門 r,打開為 sn。 如果 cm 的驗證是正確的,并且 sn 未被使用過, 則 B 可以贖回一個新的數字貨幣 ;否則本次兌換將 因為驗證失敗而被拒絕。在這個場景中,A 熔鑄的 數字貨幣與 B 贖回的數字貨幣并無任何關聯,這是因為零知識證明 π 保證不會泄露關于 cm 或 sn 的任 何有效信息。

問題

  • 但是 Zerocoin 并不完善,依舊存在一些值得改 進的地方 : 1. 在上述示例中,A 也知道 sn 和陷門 r,有可 能在 B 兌換之前先執行兌換過程,或者當 B 繼續做 數字貨幣交易時,通過追蹤 sn 來發現 B 的交易信息。 2. 匿名交易的面額固定,缺乏應用的靈活性。 3. 交易直接公布在公共賬本中,未對交易數據 隱私做特殊保護。 Zerocash 針對上述問題進行了改進,配合 zk- SNARK (zero-knowledge Succinct Non-Interactive Arguments of Knowledge) 和加密方案同時保護身份 和交易隱私。

交易隱私保護技術

  • 當前區塊鏈中實現交易隱私保護的兩項密碼技 術有 :非交互式零知識證明和同態技術。

非交互零知識證明

  • Zerocash[12] 首次應用 zk-SNARK 提供完全的用 戶隱私化和交易信息隱藏化。
  • 與 Zerocoin 相比,它 的優勢體現在以下 3 個方面。
  • 1. zk-SNARK 具有簡潔性,即驗證者只需要少 量計算就可以完成驗證 ;非交互性,即整個證明過 程僅需交換少量信息。這兩個性質對于區塊鏈非常 友好,因為區塊鏈上節點眾多,為了能夠快速達到 共識,計算復雜度和通信成本都不能過大。
  • 2. 修改數字貨幣承諾的生成方案,并使用偽隨 機函數來確定支付目標地址和序列號,即當數字貨 幣兌換后,接收方會用私鑰產生全新的序列號 sn’, 確保即使發送者知道之前的 sn,仍然無法跟蹤或兌 換該數字貨幣。
  • 3. 支持任意金額的區塊鏈交易,且通過加密技 術保證交易金額、交易隨機數、交易目標地址等信 息的隱蔽性。同時,為了驗證交易,會在零知識證 明中增加關于交易金額有效性的驗證。

問題

  • 以太坊 (Ethereum) 目前也在試圖把 Zerocash 的 隱私交易功能作為一個預編譯合約鏈接到智能合約中,即 ZoE (Zcash over Ethereum) 工程,不過即使做了預編譯優化,它能提供的隱私驗證能力也非常 有限。Hawk?則是一個完全采取 zk-SNARK 的區 塊鏈智能合約部署系統,保證了數據和計算過程在 鏈上的隱私性和可用性,在保險、股票等金融領域 有著廣泛的應用前景。

同態加密技術

  • 同態密碼是一類保持密文延展性的加密方案, 支持將密文操作映射到原始數據上,具有天然的數 據隱私性保護。以場景為例,參與方 A 擁有數據 {x1, …, xn},參與方 B 擁有計算邏輯 f(·),二者想共 同計算 f(x1, …, xn)。定義 E(·)/D(·) 為一組同態加密 方案的加 / 解密算法。首先,A 分別對數據進行加密, 將加密結果 {E(x1), …, E(xn)} 發送給 B。此時 B 按照 f 的計算邏輯執行運算得到 = f(E(x1),…,E(xn)),將 返回給 A。這時,A 使用解密算法對結果進行解密, 就可以獲得計算結果 f(x1, …, xn)。 在這個過程中,B 僅擁有密文且無法獲知 A 的數據,有效保證了數據的隱私性。區塊鏈隱私保護中常用 的同態密碼技術有 Pedersen 承諾和 Paillier 加密。

Pedersen 承諾

  • Monero 基于機密交易機制保 證交易數據的隱私性,該機制使用 到的核心技術之一就是 Pedersen 承 諾。在機密交易中,交易金額提交 到區塊鏈前首先由隨機盲化因子進 行承諾。在交易驗證過程中,由 于 Pederson 承諾的同態性,可以分 別計算交易的輸入和輸出密文的總 和,通過驗證“所有輸入輸出的總 和是否為關于 0 的承諾”來驗證交 易金額的有效性。此時交易發起者 僅需要證明他知道承諾對應的隨機數,這個證明可以使用一個標準的零知識證明來實 現,整個過程不會泄露交易的實際金額或其他交易 數據。

Paillier 加密

  • Paillier 是基于復合剩余類基本假設的同態加 密方案,它的加 / 解密形式簡單,且密文無噪聲。 Wang 等學者 [14] 使用 Paillier 加密方案構造了針對比 特幣的隱私交易系統,其中交易金額使用 Paillier 進 行隱蔽性保護,零知識證明用于檢查加密后金額的 有效性(即確保交易金額為正,并驗證輸入之和等 于輸出之和)。這些交易就像密封的資產信封,可 以合并、分離或使用,并且保持金額不可見。 另一個基于 Paillier 構造的區塊鏈隱私計算工程 是由矩陣元公司推出的計算平臺 PlatON。該平臺重 點針對以太坊的余額模型進行數據隱私保護,設計 并部署基于 Paillier 的用戶賬戶余額的密態更新,并 提出一種新的非交互式零知識證明方案 [15],用于驗 證密態交易數據的合法性。然而,這種方案解密的 時候需要求解橢圓曲線離散對數問題,在交易金額較大的時候解密性比較差。

總結與展望

  • 1. 可擴展性和經濟性 如表 1 所示,中心化 和分布式混淆方法都會產生額外的等待延遲,Zero- cash 的證明平均生成時間約為 2 分鐘,CryptoNote 中匿名交易簽名的大小與參與者的數量成正比,這 意味著存儲和通信成本也會隨匿名集的增大而增 加。因此,如何優化組合現有的隱私保護方案或設 計低成本的密碼方案是一個值得研究的方向。
  • 2. 弱假設下的強隱私保護 分布式混淆假 設一定比例的參與者是誠實的,以緩解 Sybil 攻擊 的危害 ;zk-SNARK 需要第三方生成初始化電路 ; Hawk 中每個智能合約都需要一個獨立的可信的初 始化進程。從優化安全性模型的角度來看,新的隱 私保護方案需要盡量少的安全性假設,從而增強實 際隱私保護效果。
  • 3. 兼容性 區塊鏈有兩種主流的交易模式 : 比特幣為代表的 UTXO 和以太坊為代表的 AC- COUNT。現有方案大多針對 UTXO 模型(鏈式結構) 進行隱私保護。在 ACCOUNT 模型中,賬戶為全球 狀態,交易決定賬戶狀態,相互之間沒有聯系。此 時混淆交易地址無法達到隱私效果,因此隱私保護 方法與 ACCOUNT 架構兼容是一項新的待解決問題。
  • 4. 合法監管性 區塊鏈的隱私保護是一把“雙 刃劍”。一方面,誠實用戶希望擁有信息的隱私性 ; 另一方面,惡意實體可能濫用隱私保護機制進行某 些非法交易。因此,區塊鏈隱私需要具備條件性, 即權威機構可以被授權跟蹤目標用戶的區塊鏈行 為,并收集他 / 她已經傳播的所有消息,但該用戶 的敏感信息仍然受到保護。
  • 區塊鏈概念自提出至今一直受到學術界和產業界的廣泛關注。它提供了一種完全分布式的、不可 篡改的數據存儲、共享和同步方式,非常適用于大 型分布式互聯網交互系統(例如物聯網或供應鏈系 統)。近幾年,全行業都在尋求如何使用區塊鏈來 解決各領域存在的痛點。 但是,在互聯網時代,數據即資產。日益增長 的隱私保護需求是區塊鏈落地實用前必須面對并解 決的問題之一。希望本文能為區塊鏈相關隱私問題 的探索提供引導與啟發。?

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/news/447023.shtml
繁體地址,請注明出處:http://hk.pswp.cn/news/447023.shtml
英文地址,請注明出處:http://en.pswp.cn/news/447023.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

值類型和引用類型的區別

一、定義 引用類型表示你操作的數據是同一個,也就是說當你傳一個參數給另一個方法時,你在另一個方法中改變這個變量的值,那么調用這個方法是傳入的變量的值也將改變。 值類型表示復制一個當前變量傳給方法,當你在這個方法中改變…

面向區塊鏈的高效物化視圖維護和可信查詢論文學習

物化視圖介紹 如何維護物化視圖仍舊是一個開放問題.在關系數據庫中,增量刷新的物化視圖維護策略可劃分為立即維護和延遲維護兩大類.立即維護策略的優點是實現較為簡單,在單數據源下不 存在一致性問題;然而該策略將物化視圖維護過程嵌入到更新事務之中,延長了更新事務的提交時間…

Java基礎知識(一)

一、接口 類描述了一個實體,包括實體的狀態,也包括實體可能發出的動作。 接口定義了一個實體可能發出的動作。但是只是定義了這些動作的原型,沒有實現,也沒有任何狀態信息。 所以接口有點象一個規范、一個協議,是一個…

密碼學數字信封的介紹

對稱密碼和非對稱密碼 對稱密碼:加解密運算非常快,適合處理大批量數據,但其密碼的分發與管理比較復雜非對稱密碼:公鑰和私鑰分離,非常適合密鑰的分發和管理 數字信封的定義 如果將對稱密碼算法和非對稱密碼算法的優點…

Android設計模式之——狀態模式

一、介紹 狀態模式中的行為是由狀態來決定的,不同的狀態下有不同的行為。狀態模式和策略模式的結構幾乎完全一樣,但它們的目的、本質卻完全不一樣。狀態模式的行為是平行的、不可替換的,策略模式的行為是彼此獨立、可相互替換的。用一句話來…

Android設計模式之——責任鏈模式

一、介紹 責任鏈模式(Iterator Pattern),是行為型設計模式之一。什么是”鏈“?我們將多個節點首尾相連所構成的模型稱為鏈,比如生活中常見的鎖鏈,就是由一個個圓角長方形的鐵環串起來的結構。對于鏈式結構…

目前基于區塊鏈的檔案防篡改系統的設計如何實現防篡改

架構設計圖 分析 為了保障檔案數據的安全性和隱私性,存儲檔案附件和檔案屬性存儲加密存儲在私有IPFS集群,檔案的IPFS地址和數字指紋存儲在私有區塊鏈上。公有區塊鏈定期存儲和檢查私有區塊鏈最新不可逆區塊的高度和哈希值,以保障私有區塊鏈上…

IPFS的文件存儲模式

IPFS是如何進行文件存儲的 IPFS采用的索引結構是DHT(分布式哈希表),數據結構是MerkleDAG(Merkle有向無環圖) DHT(分布式哈希表) 參考鏈接MerkleDAG(Merkle有向無環圖) 參考鏈接MerkleDAG功能…

Android設計模式之——解釋器模式

一、介紹 解釋器模式(Interpreter Pattern)是一種用的比較少的行為型模式,其提供了一種解釋語言的語法或表達式的方式,該模式定義了一個表達式接口,通過該接口解釋一個特定的上下文。在這么多的設計模式中&#xff0c…

在Docker里面安裝Ubuntu,并且使用ssh進行連接

創建Ubuntu鏡像 1,拉取Ubuntu系統的鏡像 docker pull ubuntu2、查看拉取是否成功 docker images3,運行容器 docker run --name 新建的容器的名字 -ti -v /AAA:/BBB -d -p 3316:22 ubuntu(這個是鏡像的名字)宿主機根目錄中的AAA文件夾就映射到了容器…

Android設計模式之——命令模式

一、介紹 命令模式(Command Pattern),是行為型設計模式之一。命令模式相對于其他的設計模式來說并沒有那么多的條條框框,其實它不是一個很”規范“的模式,不過,就是基于這一點,命令模式相對于其…

C++ 序列化和反序列化學習

定義 程序員在編寫應用程序的時候往往需要將程序的某些數據存儲在內存中,然后將其寫入某個文件或是將它傳輸到網絡中的另一臺計算機上以實現通訊。這些過程將會涉及到程序數據轉化成能被存儲并傳輸的格式,因此被稱為“序列化”(Serializatio…

Android設計模式之——觀察者模式

一、介紹 觀察者模式是一個使用率非常高的模式,它最常用的地方是GUI系統、訂閱——發布系統。因為這個模式的一個重要作用就是解耦,將被觀察者和觀察者解耦,使得它們之間的依賴性更小,甚至做到毫無依賴。以GUI系統來說&#xff0…

Android設計模式之——備忘錄模式

一、介紹 備忘錄模式是一種行為模式,該模式用于保存對象當前狀態,并且在之后可以再次恢復到此狀態,這有點像我們平時說的”后悔藥“。備忘錄模式實現的方式需要保證被保存的對象狀態不能被對象從外部訪問,目的是為了保護好被保存…

c++ memory 頭文件詳細介紹

類 指針特征 pointer_traits (C11) 提供關于指針式類型的信息 (類模板) 垃圾收集器支持 pointer_safety (C11) 列出指針安全模式 (枚舉) 分配器 allocator 默認的分配器 (類模板) allocator_traits (C11) 提供關于分配器類型的信息 (類模板) allocator_arg_t (C11) 標簽類型…

C++ using的三種使用策略以及具體的用法

Using的使用方法 1,命名空間的使用 為了防止代碼沖突,都會使用到命名空間。假設這樣一種情況,當一個班上有兩個名叫 Zara 的學生時,為了明確區分他們,我們在使用名字之外,不得不使用一些額外的信息&#…

Android設計模式之——迭代器模式

一、介紹 迭代器模式(Iterator Pattern)又稱為游標(Cursor)模式,是行為型設計模式之一。迭代器模式算是一個比較古老的設計模式,其源于對容器的訪問,比如Java中的List、Map、數組等&#xff0c…

Android設計模式之——模板方法模式

一、介紹 在面向對象開發過程中,通常會遇到這樣的一個問題,我們知道一個算法所需的關鍵步驟,并確定了這些步驟的執行順序,但是,某些步驟的具體實現是未知的,或者說某些步驟的實現是會隨著環境的變化而改變…

Android設計模式之——訪問者模式

一、介紹 訪問者模式是一種將數據操作與數據結構分離的設計模式,它是《設計模式》中23種設計模式中最復雜的一個,但它的使用頻率并不高,正如《設計模式》的作者GOF對訪問者模式的描述:大多數情況下,你不需要使用訪問者…

C++類模板template <class T>簡單使用方法

一個簡單的例子 兩個數比大小 如果兩個數都是int類型 class Compare_int { public :Compare(int a,int b){xa;yb;}int max( ){return (x>y)?x:y;}int min( ){return (x<y)?x:y;} private :int x,y; }; 如果兩個數是float類型 class Compare_float { public :Compare(…