Jellyfish Merkle Tree

Total Page:16

File Type:pdf, Size:1020Kb

Jellyfish Merkle Tree Jellyfish Merkle Tree Zhenhuan Gao, Yuxuan Hu, Qinfan Wu* Abstract. This paper presents Jellyfish Merkle Tree (JMT), a space-and-computation-efficient sparse Merkle tree optimized for Log-Structured Merge-tree (LSM-tree) based key-value storage, which is designed specially for the Diem Blockchain. JMT was inspired by Patricia Merkle Tree (PMT), a sparse Merkle tree structure that powers the widely known Ethereum network. JMT further makes quite a few optimizations in node key, node types and proof format to find the ideal balance between the complexity of data structure, storage, I/O overhead and computation efficiency, to cater to the needs of the Diem Blockchain. JMT has been implemented in Rust, but it is language- independent such that it could be implemented in other programming languages. Also, the JMT structure presented is of great flexibility in implementation details for fitting various practical use cases. 1 Introduction Merkle tree, since introduced by Ralph Merkle [1], has been a de facto solution to productionized account-model blockchain systems. Ethereum [2] and HyperLedger [3], are examples with various versions of Merkle trees. Although Merkle tree fits pretty well as an authenticated key-value store holding a huge amountof data in a tamper-proof way, its performance in terms of computation cost and storage footprint are two major concerns where people have been trying to achieve some enhancements. Among them, the sparseness of Merkle trees [2], [4], [5] has been aptly leveraged to cut off unnecessary complexity in more compact and efficient Merkle tree design. Virtually, a Merkle tree in reality has far fewer leaf nodes at the bottom level, a far cry from the intractable size that can be held by a perfect Merkle tree. If sticking rigorously to the original Merkle tree structure, any design will by no means escape from excessive computation and space overhead. The optimizations offered by the sparseness can also benefit other related data, notably proofs[6]. With sparseness, and its resultant smaller tree sizes, shorter proofs can be properly designed with less CPU time in generation and verification, and less network bandwidth in transmission, benefiting both server and client sides. Based on earlier works in the industry, we present JMT, a space-time win-win optimized sparse Merkle tree designed specially for such blockchain systems as the Diem Blockchain [7], [8]. JMT is built on top of an LSM-tree based key-value storage, featuring version-based key that circumvents heavy I/O brought about by the randomness of a pervading hash-based key. ∗ The authors work at Novi Financial, a subsidiary of Facebook, Inc., and contribute this paper to the Diem Association under a Creative Commons Attribution 4.0 International License. Revised January 12, 2021 1 This mini whitepaper is structured as follows: First, we give a concise retrospection of Merkle trees in practical uses cases where each leaf node is addressable via a key, followed by the variation and evolvement (Section 2). We then present JMT, including node key structure and its implicit benefits, logical data structures of two node types and related operations (Section 3). We then describe the proof format of JMT with the verification algorithm, paired with examples (Section 4). Finally, we conclude and discuss our future works (Section 5). 2 A Retrospection of Addressable Merkle Trees Merkle trees are widely adopted by the blockchain industry as a cryptographically authenticated, deterministic data structure that can be used to store and map between arbitrary binary data. In the family of Merkle trees, an addressable Merkle tree, becomes the de facto standard of authenticated data structure that keeps record of the global blockchain state. We presume the readers of this paper are familiar with the background of Merkle trees and how Merkle trees are used to allow efficient and secure verification of the contents of large data structures with proofs. 2.1 Addressable Merkle Tree (AMT) An authenticated data structure allows a verifier 푉 to hold a short authenticator 푎, which forms a binding commitment to a larger data structure 퐷. An untrusted prover 푃 , which holds 퐷, computes 푓(퐷) → 푟 and returns both 푟 — the result of the computation of some function 푓 on 퐷 — as well as 휋 — a proof of the correct computation of the result — to the verifier. 푉 can run Verify(푎, 푓, 푟, 휋), which returns true if and only if 푓(퐷) = 푟. In the context of the Diem Blockchain, provers are generally validators and verifiers are clients executing read queries. In summary, an addressable Merkle tree is an authenticated data structure as a form of a binary Merkle tree that stores maps. In a Merkle tree of size 2ℎ, the structure 퐷 maps every key 푖 ∈ [0, 2ℎ) to a value 푣푖. The authenticator is formed from the root of a full binary tree created from the values, labeling leaves as hash(푖 ‖ 푣푖) and internal nodes as hash(left ‖ right), where H is a cryptographic hash function. Keys are encoded as the binary paths from the root to each leaf which are referred to as keys in production. 1 The function 푓, which the prover wishes to authenticate, is an inclusion proof that a key-value pair (푘, 푣) is within the map 퐷. a=H(h4||h5) 0 1 h4=H(h0||h1) h5=H(h2||h3) 0 1 0 1 h0=H(0||s0) h1=H(1||s1) h2=H(2||s2) h3=H(3||s3) Figure 1: A Merkle tree storing 퐷 = {0 ∶ s0, …}. If 푓 is a function that gets the third item (shown with a dashed line) then 푟 = s2 and 휋 = [h3, h4] (these nodes are shown with a dotted line). Verify(푎, 푓, 푟, 휋) verifies that 푎 =? hash(h4 ‖ hash(hash(2 ‖ 푟) ‖ h3)). 푃 authenticates lookups for an item 푖 in 퐷 by returning a proof 휋 that consists of the labels of the sibling of each of the ancestors of node 푖. Figure 1 shows an AMT with 2-bit address where the 1 Secure Merkle trees must use different hash functions to hash the leaves and internal nodes to avoid confusion between the two types of nodes. While we have omitted this detail in the example for simplicity, the Diem Core uses a unique hash function to distinguish between different hash function types to avoid attacks based on type confusion [?]. 2 addresses of nodes in binary are 0x00, 0x01, 0x10, 0x11, respectively. The addressing process is also straightforward: Following each bit of the address from MSB to LSB, if it reaches a 0, visit the left child of the current node; otherwise, the right child. Figure 1 also illustrates a lookup for the 3푟푑 item which is surrounded by dotted lines, and the nodes included in 휋 are shown with dashed lines. In this way, the root digest, 푎, efficiently authenticates all the data stored at all the leaf nodes, addressed by their keys, altogether by recursively hashing the concatenation of the hashes of the two children. 2.1.1 Tractable Representations While a full tree with ℎ-bit keys (256 bits in Diem) of size 2ℎ is an intractable representation when ℎ is a large value, Figure 2 shows two optimizations that can be applied to transform a naive binary implementation ( 1 ) into an efficient one for a sparse Merkle tree. First, subtrees that consist entirely of empty nodes are replaced with a placeholder value (□ in 2 ) whose digest is a predefined constant 퐷푑푖푔푒푠푡 as used in the certificate transparency system9 [ ]. This optimization creates a representation of a tractable size without substantially changing the proof generation of the Merkle tree. However, leaves are always stored at the bottom level of the tree, meaning that the structure requires ℎ hashes to be computed on every leaf modification. A second optimization replaces subtrees consisting of exactly one leaf with a single node ( 3 ). In expectation, the depth of any given item is 푂(log 푛), where 푛 is the number of items in the tree. This optimization reduces the number of hashes to be computed when performing operations on the map including proof-related operations. Some works [5] create an identical default digest only for the empty nodes on the same height ℎ and ℎ ℎ−1 ℎ−1 let 퐷푑푒푓푎푢푙푡 = 퐻(퐷푑푒푓푎푢푙푡 ‖ 퐷푑푒푓푎푢푙푡). In this paper, we choose a single default digest 퐷푑푒푓푎푢푙푡 to represent empty subtrees at any level without ambiguity, especially in our design. 1 2 0 1 0 1 0 0 1 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 A B C A B C 3 0 1 A 0 1 0 1 B C Figure 2: Three versions of a sparse Merkle tree storing 퐷 = {01002 ∶ A, 10002 ∶ B, 10112 ∶ C}. 2.2 Addressable Radix Merkle Tree (ARMT) The same architecture could be extended to a more generalized radix tree since AMT is just a special case with radix 푟 = 2. In turn, an ARMT is the compressed version of the corresponding AMT such that every 푙표푔2(푟) levels of the original AMT are compressed into a single level where each node has maximum 푟 children, though some children may not exist. We will use ARrMT to denote an addressable Merkle tree with radix 푟. Notwithstanding 푟 = 2푘, 푘 ∈ ℕ+, most ARMT designs choose AR16MT in production, i.e., each internal node has up to 16 children. 3 The choice is mostly attributed from the following tradeoff between storage and I/O overhead because an update of a single leaf node can require all the nodes on the path to the root to be updated together.
Recommended publications
  • Angela: a Sparse, Distributed, and Highly Concurrent Merkle Tree
    Angela: A Sparse, Distributed, and Highly Concurrent Merkle Tree Janakirama Kalidhindi, Alex Kazorian, Aneesh Khera, Cibi Pari Abstract— Merkle trees allow for efficient and authen- with high query throughput. Any concurrency overhead ticated verification of data contents through hierarchical should not destroy the system’s performance when the cryptographic hashes. Because the contents of parent scale of the merkle tree is very large. nodes in the trees are the hashes of the children nodes, Outside of Key Transparency, this problem is gen- concurrency in merkle trees is a hard problem. The eralizable to other applications that have the need current standard for merkle tree updates is a naive locking of the entire tree as shown in Google’s merkle tree for efficient, authenticated data structures, such as the implementation, Trillian. We present Angela, a concur- Global Data Plane file system. rent and distributed sparse merkle tree implementation. As a result of these needs, we have developed a novel Angela is distributed using Ray onto Amazon EC2 algorithm for updating a batch of updates to a merkle clusters and uses Amazon Aurora to store and retrieve tree concurrently. Run locally on a MacBook Pro with state. Angela is motivated by Google Key Transparency a 2.2GHz Intel Core i7, 16GB of RAM, and an Intel and inspired by it’s underlying merkle tree, Trillian. Iris Pro1536 MB, we achieved a 2x speedup over the Like Trillian, Angela assumes that a large number of naive algorithm mentioned earlier. We expanded this its 2256 leaves are empty and publishes a new root after algorithm into a distributed merkle tree implementation, some amount of time.
    [Show full text]
  • Enabling Authentication of Sliding Window Queries on Streams
    Proof­Infused Streams: Enabling Authentication of Sliding Window Queries On Streams Feifei Li† Ke Yi‡ Marios Hadjieleftheriou‡ George Kollios† †Computer Science Department Boston University ‡AT&T Labs Inc. lifeifei, gkollios @cs.bu.edu yike, marioh @research.att.com { } { } ABSTRACT As computer systems are essential components of many crit- ical commercial services, the need for secure online transac- . tions is now becoming evident. The demand for such appli- cations, as the market grows, exceeds the capacity of individ- 0110..011 ual businesses to provide fast and reliable services, making Provider Servers outsourcing technologies a key player in alleviating issues Clients of scale. Consider a stock broker that needs to provide a real-time stock trading monitoring service to clients. Since Figure 1: The outsourced stream model. the cost of multicasting this information to a large audi- ence might become prohibitive, the broker could outsource providers, who would be in turn responsible for forwarding the stock feed to third-party providers, who are in turn re- the appropriate sub-feed to clients (see Figure 1). Evidently, sponsible for forwarding the appropriate sub-feed to clients. especially in critical applications, the integrity of the third- Evidently, in critical applications the integrity of the third- party should not be taken for granted, as the latter might party should not be taken for granted. In this work we study have malicious intent or might be temporarily compromised a variety of authentication algorithms for selection and ag- by other malicious entities. Deceiving clients can be at- gregation queries over sliding windows. Our algorithms en- tempted for gaining business advantage over the original able the end-users to prove that the results provided by the service provider, for competition purposes against impor- third-party are correct, i.e., equal to the results that would tant clients, or for easing the workload on the third-party have been computed by the original provider.
    [Show full text]
  • Providing Authentication and Integrity in Outsourced Databases Using Merkle Hash Tree’S
    Providing Authentication and Integrity in Outsourced Databases using Merkle Hash Tree's Einar Mykletun Maithili Narasimha University of California Irvine University of California Irvine [email protected] [email protected] Gene Tsudik University of California Irvine [email protected] 1 Introduction In this paper we intend to describe and summarize results relating to the use of authenticated data structures, specifically Merkle Hash Tree's, in the context of the Outsourced Database Model (ODB). In ODB, organizations outsource their data management needs to an external untrusted service provider. The service provider hosts clients' databases and offers seamless mechanisms to create, store, update and access (query) their databases. Due to the service provider being untrusted, it becomes imperative to provide means to ensure authenticity and integrity in the query replies returned by the provider to clients. It is therefore the goal of this paper to outline an applicable data structure that can support authenticated query replies from the service provider to the clients (who issue the queries). Merkle Hash Tree's (introduced in section 3) is such a data structure. 1.1 Outsourced Database Model (ODB) The outsourced database model (ODB) is an example of the well-known Client-Server model. In ODB, the Database Service Provider (also referred to as the Server) has the infrastructure required to host outsourced databases and provides efficient mechanisms for clients to create, store, update and query the database. The owner of the data is identified as the entity who has to access to add, remove, and modify tuples in the database. The owner and the client may or may not be the same entity.
    [Show full text]
  • Návrh a Implementace Rozšíření Do Systému Phabricator
    Masarykova univerzita Fakulta informatiky Návrh a implementace rozšíření do systému Phabricator Diplomová práce Lukáš Jagoš Brno, podzim 2019 Masarykova univerzita Fakulta informatiky Návrh a implementace rozšíření do systému Phabricator Diplomová práce Lukáš Jagoš Brno, podzim 2019 Na tomto místě se v tištěné práci nachází oficiální podepsané zadání práce a prohlášení autora školního díla. Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Lukáš Jagoš Vedoucí práce: Martin Komenda i Poděkování Srdečně chci na tomto místě poděkovat vedoucímu mé diplomové práce RNDr. Martinu Komendovi, Ph.D. za cenné náměty a odborné vedení. Dále chci poděkovat Mgr. Matěji Karolyi za všestrannou po- moc při implementaci praktické části práce a Ing. Mgr. Janu Krejčímu za zpřístupnění testovacího serveru a technickou podporu. iii Shrnutí Diplomová práce se zabývá nástroji pro projektové řízení. V teore- tické části jsou vymezeny pojmy projekt a projektové řízení. Poté jsou představeny vybrané softwarové nástroje pro projektové řízení a je provedeno jejich srovnání. Pozornost je zaměřena na systém Phabrica- tor, který je v práci detailně popsán. V praktické části je navrženo rozšíření Phabricatoru na základě analýzy potřeb a sběru požadavků. Výsledkem je rozšířující modul po- skytující přehledné informace o úkolech z pohledu času a náročnosti, čímž zefektivní jejich plánování a proces týmové spolupráce. iv Klíčová slova projektové řízení, Phabricator, PHP, reportovací modul, SCRUM v Obsah 1 Projektové řízení 3 1.1 Projekt a projektové řízení ..................3 1.2 SW nástroje pro projektové řízení ...............4 1.3 Přehled nástrojů z oblasti řízení projektů ...........6 1.3.1 Phabricator .
    [Show full text]
  • The SCADS Toolkit Nick Lanham, Jesse Trutna
    The SCADS Toolkit Nick Lanham, Jesse Trutna (it’s catching…) SCADS Overview SCADS is a scalable, non-relational datastore for highly concurrent, interactive workloads. Scale Independence - as new users join No changes to application Cost per user doesn’t increase Request latency doesn’t change Key Innovations 1. Performance safe query language 2. Declarative performance/consistency tradeoffs 3. Automatic scale up and down using machine learning Toolkit Motivation Investigated other open-source distributed key-value stores Cassandra, Hypertable, CouchDB Monolithic, opaque point solutions Make many decisions about how to architect the system a -prori Want set of components to rapidly explore the space of systems’ design Extensible components communicate over established APIs Understand the implications and performance bottlenecks of different designs SCADS Components Component Responsibilities Storage Layer Persist and serve data for a specified key responsibility Copy and sync data between storage nodes Data Placement Layer Assign node key responsibilities Manage replication and partition factors Provide clients with key to node mapping Provides mechanism for machine learning policies Client Library Hides client interaction with distributed storage system Provides higher-level constructs like indexes and query language Storage Layer Key-value store that supports range queries built on BDB API Record get(NameSpace ns, RecordKey key) list<Record> get_set (NameSpace ns, RecordSet rs ) bool put(NameSpace ns, Record rec) i32 count_set(NameSpace ns, RecordSet rs) bool set_responsibility_policy(NameSpace ns,RecordSet policy) RecordSet get_responsibility_policy(NameSpace ns) bool sync_set(NameSpace ns, RecordSet rs, Host h, ConflictPolicy policy) bool copy_set(NameSpace ns, RecordSet rs, Host h) bool remove_set(NameSpace ns, RecordSet rs) Storage Layer Storage Layer Storage Layer: Synchronize Replicas may diverge during network partitions (in order to preserve availability).
    [Show full text]
  • Authentication of Moving Range Queries
    Authentication of Moving Range Queries Duncan Yung Eric Lo Man Lung Yiu ∗ Department of Computing Hong Kong Polytechnic University {cskwyung, ericlo, csmlyiu}@comp.polyu.edu.hk ABSTRACT the user leaves the safe region, Thus, safe region is a powerful op- A moving range query continuously reports the query result (e.g., timization for significantly reducing the communication frequency restaurants) that are within radius r from a moving query point between the user and the service provider. (e.g., moving tourist). To minimize the communication cost with The query results and safe regions returned by LBS, however, the mobile clients, a service provider that evaluates moving range may not always be accurate. For instance, a hacker may infiltrate queries also returns a safe region that bounds the validity of query the LBS’s servers [25] so that results of queries all include a partic- results. However, an untrustworthy service provider may report in- ular location (e.g., the White House). Furthermore, the LBS may be correct safe regions to mobile clients. In this paper, we present effi- self-compromised and thus ranks sponsored facilities higher than cient techniques for authenticating the safe regions of moving range actual query result. The LBS may also return an overly large safe queries. We theoretically proved that our methods for authenticat- region to the clients for the sake of saving computing resources and ing moving range queries can minimize the data sent between the communication bandwidth [22, 16, 30]. On the other hand, the LBS service provider and the mobile clients. Extensive experiments are may opt to return overly small safe regions so that the clients have carried out using both real and synthetic datasets and results show to request new safe regions more frequently, if the LBS charges fee that our methods incur small communication costs and overhead.
    [Show full text]
  • Executing Large Scale Processes in a Blockchain
    The current issue and full text archive of this journal is available on Emerald Insight at: www.emeraldinsight.com/2514-4774.htm JCMS 2,2 Executing large-scale processes in a blockchain Mahalingam Ramkumar Department of Computer Science and Engineering, Mississippi State University, 106 Starkville, Mississippi, USA Received 16 May 2018 Revised 16 May 2018 Abstract Accepted 1 September 2018 Purpose – The purpose of this paper is to examine the blockchain as a trusted computing platform. Understanding the strengths and limitations of this platform is essential to execute large-scale real-world applications in blockchains. Design/methodology/approach – This paper proposes several modifications to conventional blockchain networks to improve the scale and scope of applications. Findings – Simple modifications to cryptographic protocols for constructing blockchain ledgers, and digital signatures for authentication of transactions, are sufficient to realize a scalable blockchain platform. Originality/value – The original contributions of this paper are concrete steps to overcome limitations of current blockchain networks. Keywords Cryptography, Blockchain, Scalability, Transactions, Blockchain networks Paper type Research paper 1. Introduction A blockchain broadcast network (Bozic et al., 2016; Croman et al., 2016; Nakamoto, 2008; Wood, 2014) is a mechanism for creating a distributed, tamper-proof, append-only ledger. Every participant in the broadcast network maintains a copy, or some representation, of the ledger. Ledger entries are made by consensus on the states of a process “executed” on the blockchain. As an example, in the Bitcoin (Nakamoto, 2008) process: (1) Bitcoin transactions transfer Bitcoins from a wallet to one or more other wallets. (2) Bitcoins created by “mining” are added to the miner’s wallet.
    [Show full text]
  • IB Case Study Vocabulary a Local Economy Driven by Blockchain (2020) Websites
    IB Case Study Vocabulary A local economy driven by blockchain (2020) Websites Merkle Tree: https://blockonomi.com/merkle-tree/ Blockchain: https://unwttng.com/what-is-a-blockchain Mining: https://www.buybitcoinworldwide.com/mining/ Attacks on Cryptocurrencies: https://blockgeeks.com/guides/hypothetical-attacks-on-cryptocurrencies/ Bitcoin Transaction Life Cycle: https://ducmanhphan.github.io/2018-12-18-Transaction-pool-in- blockchain/#transaction-pool 51 % attack - a potential attack on a blockchain network, where a single entity or organization can control the majority of the hash rate, potentially causing a network disruption. In such a scenario, the attacker would have enough mining power to intentionally exclude or modify the ordering of transactions. Block - records, which together form a blockchain. ... Blocks hold all the records of valid cryptocurrency transactions. They are hashed and encoded into a hash tree or Merkle tree. In the world of cryptocurrencies, blocks are like ledger pages while the whole record-keeping book is the blockchain. A block is a file that stores unalterable data related to the network. Blockchain - a data structure that holds transactional records and while ensuring security, transparency, and decentralization. You can also think of it as a chain or records stored in the forms of blocks which are controlled by no single authority. Block header – main way of identifying a block in a blockchain is via its block header hash. The block hash is responsible for block identification within a blockchain. In short, each block on the blockchain is identified by its block header hash. Each block is uniquely identified by a hash number that is obtained by double hashing the block header with the SHA256 algorithm.
    [Show full text]
  • Efficient Verification of Shortest Path Search Via Authenticated Hints Man Lung YIU Hong Kong Polytechnic University
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Institutional Knowledge at Singapore Management University Singapore Management University Institutional Knowledge at Singapore Management University Research Collection School Of Information Systems School of Information Systems 3-2010 Efficient Verification of Shortest Path Search Via Authenticated Hints Man Lung YIU Hong Kong Polytechnic University Yimin LIN Singapore Management University, [email protected] Kyriakos MOURATIDIS Singapore Management University, [email protected] DOI: https://doi.org/10.1109/ICDE.2010.5447914 Follow this and additional works at: https://ink.library.smu.edu.sg/sis_research Part of the Databases and Information Systems Commons, and the Numerical Analysis and Scientific omputC ing Commons Citation YIU, Man Lung; LIN, Yimin; and MOURATIDIS, Kyriakos. Efficient Verification of Shortest Path Search Via Authenticated Hints. (2010). ICDE 2010: IEEE 26th International Conference on Data Engineering: Long Beach, California, USA, 1 - 6 March 2010. 237-248. Research Collection School Of Information Systems. Available at: https://ink.library.smu.edu.sg/sis_research/507 This Conference Proceeding Article is brought to you for free and open access by the School of Information Systems at Institutional Knowledge at Singapore Management University. It has been accepted for inclusion in Research Collection School Of Information Systems by an authorized administrator of Institutional Knowledge at Singapore Management University.
    [Show full text]
  • Redactable Hashing for Time Verification
    Technical Disclosure Commons Defensive Publications Series January 2021 Redactable Hashing for Time Verification Jan Schejbal Follow this and additional works at: https://www.tdcommons.org/dpubs_series Recommended Citation Schejbal, Jan, "Redactable Hashing for Time Verification", Technical Disclosure Commons, (January 24, 2021) https://www.tdcommons.org/dpubs_series/3999 This work is licensed under a Creative Commons Attribution 4.0 License. This Article is brought to you for free and open access by Technical Disclosure Commons. It has been accepted for inclusion in Defensive Publications Series by an authorized administrator of Technical Disclosure Commons. Schejbal: Redactable Hashing for Time Verification REDACTABLE HASHING FOR TIME VERIFICATION Cryptographic hashes (outputs of cryptographically secure hash functions) are used to uniquely identify secret information without making such information public. A cryptographic hash function is a deterministic computation that produces the same outputs for the same inputs while ensuring that even a small change of the input (e.g., a change of only one or several bits) results in an unpredictable output that has little resemblance to the original (unmodified) input. Furthermore, it is not possible to efficiently find an input matching a certain hash value or two different inputs having the same hash value; an attacker that attempts to do so would need to test numerous values until one matches, which is computationally infeasible for a sufficiently large space of possible values. The quasi-randomness property of hashes makes them useful for mapping protected information while ensuring that the information is not easily discoverable by a malicious attacker or an unauthorized viewer. Hashes can be used to derive cryptographic keys from other (strong or even weak) cryptographic material.
    [Show full text]
  • "On Merkle Trees", Dr Craig S Wright
    On Merkle Trees Dr Craig S Wright By now, it should be well understood that Bitcoin utilises the concept of a Merkle tree to its advantage; by way of background, we provide an explanation in this post. The following aids as a technical description and definition of similar concepts used more generally in Bitcoin and specifically within SPV. Merkle trees are hierarchical data structures that enable secure verification of collections of data. In a Merkle tree, each node in the tree has been given an index pair (i, j) and is represented as N(i, j). The indices i, j are simply numerical labels that are related to a specific position in the tree. An important feature of the Merkle tree is that the construction of each of its nodes is governed by the following (simplified) equations: 퐻(퐷 ) 푖 = 푗 푁(푖, 푗) = { 푖 , 퐻(푁(푖, 푘) ∥ 푁(푘 + 1, 푗)) 푖 ≠ 푗 where 푘 = (푖 + 푗 − 1)⁄2 and H is a cryptographic hash function. A labelled, binary Merkle tree constructed according to the equations is shown in figure 1, from which we can see that the i = j case corresponds to a leaf node, which is simply the hash of the th corresponding i packet of data Di. The 푖 ≠ 푗 case corresponds to an internal or parent node, which is generated by recursively hashing and concatenating child nodes, until one parent (the Merkle root) is found. Figure 1. A Merkle tree. For example, the node 푁(1,4) is constructed from the four data packets 퐷1, … , 퐷4 as 푁(1,4) = 퐻(푁(1,2) ∥ 푁(3,4)) .
    [Show full text]
  • Le Linked Data À L'université: La Plateforme Linkedwiki
    Le Linked Data à l’université : la plateforme LinkedWiki Karima Rafes To cite this version: Karima Rafes. Le Linked Data à l’université : la plateforme LinkedWiki. Web. Université Paris Saclay (COmUE), 2019. Français. NNT : 2019SACLS032. tel-02003672 HAL Id: tel-02003672 https://tel.archives-ouvertes.fr/tel-02003672 Submitted on 1 Feb 2019 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Le Linked Data NNT : 2019SACLS032 à l’université la plateforme LinkedWiki Thèse de doctorat de l’Université Paris-Saclay préparée à l’Université Paris-Sud École doctorale n◦580 Sciences et technologies de l’information et de la communication (STIC) Spécialité de doctorat : réseaux, information et communications Thèse présentée et soutenue à Gif-sur-Yvette, le 25 janvier 2019, par Karima Rafes Composition du jury : Philippe Pucheral Professeur, Université de Versailles-Saint-Quentin-en-Yvelines, Inria Président Cédric Du Mouza Maître de conférences HDR, Cnam Paris — Cédric Rapporteur Dan Vodislav Professeur, U. Cergy-Pontoise — ETIS Rapporteur Khalid Belhajjame Maître
    [Show full text]