diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 726dea0b9fff090..7e8ecd871480205 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -21,3 +21,12 @@ products/gateway/ @abracchi-tw # Warp Client products/warpclient/ @abracchi-tw + +# Randomness Beacon +products/randomness-beacon/ @ltv511 @armfazh + +# Distributed Web +products/distributed-web/ @ltv511 @thibmeu @jhoyla @Lekensteyn + +# Time Services +products/time-services/ @ltv511 @wbl @armfazh diff --git a/products/distributed-web/src/content/ethereum-gateway/about-eth.md b/products/distributed-web/src/content/ethereum-gateway/about-eth.md index 14f973d98607b12..36b4083216d2c32 100644 --- a/products/distributed-web/src/content/ethereum-gateway/about-eth.md +++ b/products/distributed-web/src/content/ethereum-gateway/about-eth.md @@ -1,8 +1,9 @@ --- -title: About Ethereum -weight: 2 +order: 2 --- +# About Ethereum + The Ethereum network is a distributed consensus platform that allows users to write and compute smart contracts in a distributed manner. Smart contracts are essentially Turing complete programs that are available at a unique address of @@ -10,7 +11,7 @@ the network. When the smart contract is run as part of a transaction, the result and the current state of the contract are stored in a verifiable consensus that is agreed upon by the entire network of nodes. -### Smart contracts +## Smart contracts When a user wants to run a smart contract on some desired inputs, they provide currency known as ETH with their command. This currency is allocated to a @@ -22,7 +23,7 @@ in the network then this is also recorded in the consensus. As such, this consensus represents the current state of the network along with exactly how much Ethereum currency is owned by each individual. -### Addressing +## Addressing All transactions on the network are stored in 'blocks' that make up the entire consensus. In brief, the consensus is a single sequence of blocks with @@ -38,7 +39,7 @@ block, this update is sent around the entire network and anyone can read the nature of the transaction that took place. This makes the entire state of the network accountable. -### Reading & writing content +## Reading & writing content To read content, a user needs to interact with a working Ethereum node. Such nodes can be run locally on a user's machine as daemons (such as: @@ -56,15 +57,15 @@ sent to the wider network and added to the consensus. Reading and writing content to the Ethereum network can be done using Cloudflare's Gateway. To learn more about how to do this see [Interacting with -the Ethereum network](../interacting-with-the-eth-gateway). +the Ethereum network](./interacting-with-the-eth-gateway). -### Connect your website to the gateway +## Connect your website to the gateway If you want to be able to access the Ethereum network accessible from a custom domain name, you can do that using Cloudflare’s Ethereum Gateway. To -learn how, check out [Connecting your Website](../connecting-your-website). +learn how, check out [Connecting your Website](./connecting-your-website). -### Going Further +## Going Further If you’re interested in learning more, you can read the official [RPC documentation](https://github.com/ethereum/wiki/wiki/JSON-RPC), along with the diff --git a/products/distributed-web/src/content/ethereum-gateway/connecting-your-website.md b/products/distributed-web/src/content/ethereum-gateway/connecting-your-website.md index 54bee4107718836..9240b1d3d627c65 100644 --- a/products/distributed-web/src/content/ethereum-gateway/connecting-your-website.md +++ b/products/distributed-web/src/content/ethereum-gateway/connecting-your-website.md @@ -1,13 +1,13 @@ --- -title: Connecting your Website -weight: 3 +order: 3 --- +# Connecting your Website You can connect your own domain name to to allow Ethereum network access from your own domain. This means that anyone can send the HTTP (JSON RPC) queries as given in [Interacting with the Ethereum -Gateway](https://developers.cloudflare.com/distributed-web/ethereum-gateway/interacting-with-the-eth-gateway/) +Gateway](./interacting-with-the-eth-gateway/) to your own domain. To do this, you should replace `https://cloudflare-eth.com` with your domain, e.g. `myethereumgateway.xyz`, as the target of the HTTP query. @@ -19,7 +19,7 @@ you need to: 1. Go to your DNS settings for your domain. If your website is on Cloudflare, the DNS settings are accessible from your dashboard. If your website is not on Cloudflare, and you need help finding the DNS records, you can use -[DomaninTools](https://whois.domaintools.com/) to identify your registrar. +[DomainTools](https://whois.domaintools.com/) to identify your registrar. 2. Add a CNAME record from your domain (e.g. www.example.com) to cloudflare-eth.com. Note: if your website is on Cloudflare, the little cloud next to this record will automatically turn grey. Because you’ve CNAME’d to diff --git a/products/distributed-web/src/content/ethereum-gateway/getting-started.md b/products/distributed-web/src/content/ethereum-gateway/getting-started.md index c4b6ff35e9810c7..23a507756c2b237 100644 --- a/products/distributed-web/src/content/ethereum-gateway/getting-started.md +++ b/products/distributed-web/src/content/ethereum-gateway/getting-started.md @@ -1,8 +1,9 @@ --- -title: Getting started -weight: 1 +order: 1 --- +# Getting started + Cloudflare's Ethereum Gateway is part of the wider Distributed Web Gateway offering, specifically providing access to the Ethereum network. In particular, users can read all information that has been agreed upon by the consensus of diff --git a/products/distributed-web/src/content/ethereum-gateway/index.md b/products/distributed-web/src/content/ethereum-gateway/index.md index 639319e169d6473..ed31cc13d1c413f 100644 --- a/products/distributed-web/src/content/ethereum-gateway/index.md +++ b/products/distributed-web/src/content/ethereum-gateway/index.md @@ -1,14 +1,15 @@ --- -title: Ethereum Gateway -weight: 3 +order: 3 --- +# Ethereum Gateway + Cloudflare's Ethereum Gateway lets you interact with the Ethereum network without installing any software on your computer. Our gateway makes it possible to add interactive elements to sites powered by Ethereum smart contracts on a decentralized compute platform. Combined with the -[IPFS gateway](/distributed-web/ipfs-gateway/), you have decentralized web and +[IPFS gateway](/ipfs-gateway/), you have decentralized web and resource hosting with the added speed, security, and reliability of the Cloudflare edge network. And you have direct access our Ethereum Gateway at [https://cloudflare-eth.com](https://cloudflare-eth.com). diff --git a/products/distributed-web/src/content/ethereum-gateway/interacting-with-the-eth-gateway.md b/products/distributed-web/src/content/ethereum-gateway/interacting-with-the-eth-gateway.md index 4edf91f7f94c294..4411864323b7236 100644 --- a/products/distributed-web/src/content/ethereum-gateway/interacting-with-the-eth-gateway.md +++ b/products/distributed-web/src/content/ethereum-gateway/interacting-with-the-eth-gateway.md @@ -1,13 +1,13 @@ --- -title: Interacting with Ethereum -weight: 4 +order: 4 --- +# Interacting with Ethereum Interacting with the network via the Cloudflare Distributed Web Gateway is as simple as specifying the correct JSON blob for your query! -### Reading from the network +## Reading from the network The Cloudflare Ethereum Gateway allows HTTP requests where the body of the request is set to be the JSON body of the request you would like to make. For @@ -84,7 +84,7 @@ The response in both cases will be a JSON blob of the form: For a full list of possible queries, along with examples see the official [RPC documentation](https://github.com/ethereum/wiki/wiki/JSON-RPC#json-rpc-api-reference). -### Writing to the network +## Writing to the network Currently the Ethereum Gateway allows you to write to the network using the `eth_sendRawTransaction` RPC method. This creates a new message call transaction @@ -131,7 +131,7 @@ await fetch(new Request("https://cloudflare-eth.com", { _(The actual command above will not work, you need to provide your own signed transaction!)_ -### Cloudflare supported API +## Cloudflare supported API The full list of API methods that are supported by the Distributed Web Gateway is given below. The Gateway returns a `403` if a method is specified that is not diff --git a/products/distributed-web/src/content/ethereum-gateway/kill-switches.md b/products/distributed-web/src/content/ethereum-gateway/kill-switches.md index 45c80d29d1b9b31..82cd70101ae597c 100644 --- a/products/distributed-web/src/content/ethereum-gateway/kill-switches.md +++ b/products/distributed-web/src/content/ethereum-gateway/kill-switches.md @@ -1,9 +1,10 @@ --- -title: Kill Switches -weight: 5 +order: 5 --- -### DAO example: Kill Switches +# Kill Switches + +## DAO example: Kill Switches When writing contracts, be especially careful to write secure code and include a kill switch to ensure that if any bugs do reside in the code, they can be @@ -27,7 +28,7 @@ investors funds. However, not everyone agreed with the chain, with those who disagreed rejecting the irregular block and forming the Ethereum Classic network, each blockchain grew independently. -### Be-all end-all solution? +## Be-all end-all solution? Hardly. Kill switches can cause their own problems. Like if a contract that's a library has its kill switch flipped. All contracts relying on this contract diff --git a/products/distributed-web/src/content/index.md b/products/distributed-web/src/content/index.md index 00d83664d448aca..f65c22965acb97d 100644 --- a/products/distributed-web/src/content/index.md +++ b/products/distributed-web/src/content/index.md @@ -1,7 +1,11 @@ --- +title: Welcome order: 0 +type: overview --- -# Welcome +# Simple, secure access to the Distributed Web -TODO... +View files stored on the InterPlanetary File System in your browser. Interact with the Ethereum blockchain. Explore the Distributed Web. + +IPFS Gateway   Ethereum Gateway diff --git a/products/distributed-web/src/content/ipfs-gateway/automated-deployment.md b/products/distributed-web/src/content/ipfs-gateway/automated-deployment.md index 418aa824f2e49f9..0be6a2307f91296 100644 --- a/products/distributed-web/src/content/ipfs-gateway/automated-deployment.md +++ b/products/distributed-web/src/content/ipfs-gateway/automated-deployment.md @@ -1,8 +1,9 @@ --- -title: Automated Deployment -weight: 4 +order: 4 --- +# Automated Deployment + Static sites are pretty easy to deploy automatically. The code of the site is usually kept in a Git repository and deployed by pushing the latest commit to a repository that's connected to a Continuous Integration service like [Travis diff --git a/products/distributed-web/src/content/ipfs-gateway/browsing-ipfs.md b/products/distributed-web/src/content/ipfs-gateway/browsing-ipfs.md index 3a3634d344384eb..e2be8bb01eadd5c 100755 --- a/products/distributed-web/src/content/ipfs-gateway/browsing-ipfs.md +++ b/products/distributed-web/src/content/ipfs-gateway/browsing-ipfs.md @@ -1,13 +1,14 @@ --- -title: Browsing Content on IPFS -weight: 1 +order: 1 --- +# Browsing Content on IPFS + Browsing IPFS using Cloudflare's gateway requires two things: a browser connected to the Internet, and the address of something on IPFS that you want to view. -As mentioned on the [introduction](/distributed-web/ipfs-gateway/) page, every file added to the +As mentioned on the [introduction](/ipfs-gateway/) page, every file added to the IPFS network is given a unique address based on its contents which is called a Content Identifier, or CID. So if you have an image stored on IPFS, its CID would be based on the hash of the bits that compose that image. diff --git a/products/distributed-web/src/content/ipfs-gateway/connecting-website.md b/products/distributed-web/src/content/ipfs-gateway/connecting-website.md index 274e441b1cd6b47..6eb93cf12668d02 100755 --- a/products/distributed-web/src/content/ipfs-gateway/connecting-website.md +++ b/products/distributed-web/src/content/ipfs-gateway/connecting-website.md @@ -1,9 +1,10 @@ --- -title: Connecting Your Website -weight: 3 +order: 3 hidden: true --- +# Connecting Your Website + Cloudflare's gateway allows you to host your website on IPFS and still have it accessible from a custom domain name. This allows an end user to access your website without needing to memorize any hash or download any software. Plus, diff --git a/products/distributed-web/src/content/ipfs-gateway/index.md b/products/distributed-web/src/content/ipfs-gateway/index.md index e3c42ee8391d2e5..eff942f8e636e55 100755 --- a/products/distributed-web/src/content/ipfs-gateway/index.md +++ b/products/distributed-web/src/content/ipfs-gateway/index.md @@ -1,8 +1,9 @@ --- -title: IPFS Gateway -weight: 2 +order: 2 --- +# IPFS Gateway + Cloudflare's read-only Distributed Web Gateway lets you access content stored on the InterPlanetary File System \(IPFS\) quickly and easily, without downloading any special software or giving up any storage space on your computer. diff --git a/products/distributed-web/src/content/ipfs-gateway/setting-up-a-server.md b/products/distributed-web/src/content/ipfs-gateway/setting-up-a-server.md index a24f01df2e23866..5981c8b18d56d34 100644 --- a/products/distributed-web/src/content/ipfs-gateway/setting-up-a-server.md +++ b/products/distributed-web/src/content/ipfs-gateway/setting-up-a-server.md @@ -1,8 +1,9 @@ --- -title: Setting Up a Server -weight: 2 +order: 2 --- +# Setting Up a Server + While all IPFS nodes are created equal, some are better suited for different purposes depending on their setup. An IPFS node running on your laptop, for instance, isn't very good for hosting a website because your website will go diff --git a/products/distributed-web/src/content/ipfs-gateway/troubleshooting.md b/products/distributed-web/src/content/ipfs-gateway/troubleshooting.md index 3ae4824c2e6c855..10475d8637b7c6e 100644 --- a/products/distributed-web/src/content/ipfs-gateway/troubleshooting.md +++ b/products/distributed-web/src/content/ipfs-gateway/troubleshooting.md @@ -1,8 +1,9 @@ --- -title: Troubleshooting -weight: 10 +order: 10 --- +# Troubleshooting + IPFS is still a developing protocol and content is often unavailable or slow to load for reasons outside of Cloudflare's control. Usually, this happens for one of the following reasons: diff --git a/products/distributed-web/src/content/ipfs-gateway/updating-for-ipfs.md b/products/distributed-web/src/content/ipfs-gateway/updating-for-ipfs.md index 4a783b1c9cd57da..d8cf31f9025a933 100644 --- a/products/distributed-web/src/content/ipfs-gateway/updating-for-ipfs.md +++ b/products/distributed-web/src/content/ipfs-gateway/updating-for-ipfs.md @@ -1,8 +1,9 @@ --- -title: Updating your Website for IPFS -weight: 3 +order: 3 --- +# Updating your Website for IPFS + It's not required, but it is strongly recommended that websites hosted on IPFS use only relative links, unless linking to a different domain. This is because data can be accessed in many different (but ultimately equivalent) ways: diff --git a/products/randomness-beacon/src/content/about/Background.md b/products/randomness-beacon/src/content/about/Background.md index 901ba5ca8e6b352..a5fdb2b649f5903 100644 --- a/products/randomness-beacon/src/content/about/Background.md +++ b/products/randomness-beacon/src/content/about/Background.md @@ -1,19 +1,19 @@ --- title: Background -weight: 10 +order: 1 --- -# Where did it all begin? +# Where did it all begin? Over the years, a generation of public randomness (often referred to as _common coins_) has attracted continuous interest from the cryptography research community. Many distributed systems, including various consensus mechanisms, anonymity networks such as Tor, or blockchain systems, assume access to such public randomness. However, it remained a major unsolved issue to generate public randomness in a distributed, scalable, and robust way. Currently, there is no service deployed to produce this type of randomness. The only choice is a centralized, prototype-only randomness beacon run by [NIST](https://www.nist.gov/). Realizing this, [Ewa Syta](http://ewa.syta.us/) started a project on [Scalable Bias-Resistant Distributed Randomness](https://eprint.iacr.org/2016/1067) during her PhD studies under the supervision of [Michael J. Fischer](http://www.cs.yale.edu/homes/fischer/) and [Bryan Ford](https://bford.info/) at Yale University. After Bryan moved to EPFL in 2015, the new members of the DEDIS team at EPFL ([Nicolas Gailly](https://github.com/nikkolasg/), [Linus Gasser](https://people.epfl.ch/linus.gasser), [Philipp Jovanovic](https://jovanovic.io/), [Ismail Khoffi](https://ismailkhoffi.com/), [Eleftherios Kokoris Kogias](https://lefteriskk.github.io/)) joined the project and together published a research paper at the [2017 IEEE Symposium on Security and Privacy](https://ieeexplore.ieee.org/abstract/document/7958592). - -The paper explored the use of key pairings instead of classical elliptic curve cryptography to generate public randomness as a way to simplify the proposed protocol designs and improve performance in terms of randomness generation and verification. -In early 2017, the [DEDIS](https://dedis.epfl.ch/) team at [EPFL](https://www.epfl.ch/en/) started collaborating with [DFINITY](https://dfinity.org/) on various research topics, inlcuding public randomness. The DFINITY architecture is built around a pairing-based randomness beacon sharing similarities to the constructs described in the DEDIS paper. Additionally, DFINITY has already implemented an optimized pairing library in C++. After integrating this implementation into the DEDIS’ crypto library [Kyber](https://github.com/dedis/kyber), all major cryptographic components were ready to implement an efficient, distributed randomness generation protocol using pairings. +The paper explored the use of key pairings instead of classical elliptic curve cryptography to generate public randomness as a way to simplify the proposed protocol designs and improve performance in terms of randomness generation and verification. + +In early 2017, the [DEDIS](https://dedis.epfl.ch/) team at [EPFL](https://www.epfl.ch/en/) started collaborating with [DFINITY](https://dfinity.org/) on various research topics, inlcuding public randomness. The DFINITY architecture is built around a pairing-based randomness beacon sharing similarities to the constructs described in the DEDIS paper. Additionally, DFINITY has already implemented an optimized pairing library in C++. After integrating this implementation into the DEDIS’ crypto library [Kyber](https://github.com/dedis/kyber), all major cryptographic components were ready to implement an efficient, distributed randomness generation protocol using pairings. In September 2017, Nicolas, a PhD student at DEDIS, started coding drand with the help of Philipp to deploy, for the first time, a distributed service providing public randomness in an application-agnostic, secure, and efficient way. A short time later, Cloudflare released an optimized Golang implementation of the BN256 pairing curve, which is now integrated in both Kyber and drand to simplify development and deployment. diff --git a/products/randomness-beacon/src/content/about/Drand.md b/products/randomness-beacon/src/content/about/Drand.md index 5abab1f495d607f..1515e4476648a88 100644 --- a/products/randomness-beacon/src/content/about/Drand.md +++ b/products/randomness-beacon/src/content/about/Drand.md @@ -1,10 +1,9 @@ --- title: Drand Project -weight: 10 +order: 0 --- -## What is drand? - +# What is drand? The drand project aims to address the current lack of services providing distributed public randomness. Distributed to increase the reasilience and trustworthiness. drand provides a standalone randomness-as-a-service network that is application agnostic. For example, similar to NTP networks serving timing information accross the globe. drand follows the [KISS principle](https://en.wikipedia.org/wiki/KISS_principle), relying on well-researched cryptographic building blocks and open-source software design principles and libraries, such as protobuf and gRPC, to ensure high performance and interoperability. drand also attempts to use sane security defaults, such as having TLS enabled by default. diff --git a/products/randomness-beacon/src/content/about/future.md b/products/randomness-beacon/src/content/about/Future.md similarity index 92% rename from products/randomness-beacon/src/content/about/future.md rename to products/randomness-beacon/src/content/about/Future.md index 904f39167d9d51b..7c62417a324f354 100644 --- a/products/randomness-beacon/src/content/about/future.md +++ b/products/randomness-beacon/src/content/about/Future.md @@ -1,9 +1,9 @@ --- title: Future of Drand -weight: 10 +order: 2 --- -## What do you see as the future of this project? +# What do you see as the future of this project? As of spring 2020, the drand network is production-ready, and we believe that it can now be considered foundational Internet infrastructure, much like DNS or BGP. diff --git a/products/randomness-beacon/src/content/about/index.md b/products/randomness-beacon/src/content/about/index.md index 6c6dec7ee12df5a..1926df579a9d221 100644 --- a/products/randomness-beacon/src/content/about/index.md +++ b/products/randomness-beacon/src/content/about/index.md @@ -1,6 +1,11 @@ --- -title: About -weight: 10 +order: 1 --- -Learn more about [drand](https://drand.love/): a distributed service providing public randomness in an application-agnostic, secure, and efficient way. \ No newline at end of file +# About Drand + +Drand (pronounced "dee-rand") is a distributed randomness beacon daemon written in Golang. Servers running drand can be linked with each other to produce collective, publicly verifiable, unbiased, unpredictable random values at fixed intervals using bilinear pairings and threshold cryptography. + +Drand is meant to be an Internet infrastructure level service that provides randomness to applications, similar to how NTP provides timing information and Certificate Transparency servers provide certificate revocation information. + +For the most up-to-date documentation on drand, please visit [drand.love](https://drand.love). \ No newline at end of file diff --git a/products/randomness-beacon/src/content/cryptographic-background/index.md b/products/randomness-beacon/src/content/cryptographic-background/index.md index 25193f92ef01856..feee3d4d46c9ccd 100644 --- a/products/randomness-beacon/src/content/cryptographic-background/index.md +++ b/products/randomness-beacon/src/content/cryptographic-background/index.md @@ -1,8 +1,9 @@ --- -title: Cryptographic Background -weight: 30 +order: 2 --- +# Cryptographic Background + drand is an efficient randomness beacon daemon that utilizes pairing-based cryptography, `𝑡-of-𝑛` distributed key generation, and threshold BLS signatures to generate publicly-verifiable, unbiasable, unpredictable, distributed randomness. This is an overview of the cryptographic building blocks drand uses to generate publicly-verifiable, unbiasable, and unpredictable randomness in a distributed manner. diff --git a/products/randomness-beacon/src/content/cryptographic-background/randomness-generation.md b/products/randomness-beacon/src/content/cryptographic-background/randomness-generation.md new file mode 100644 index 000000000000000..4db37884e76a043 --- /dev/null +++ b/products/randomness-beacon/src/content/cryptographic-background/randomness-generation.md @@ -0,0 +1,94 @@ +--- +order: 1 +--- + +# Randomness Generation + +In this section, we describe how to use this collective key pair to generate publicly-verifiable, unbiasable, and unpredictable randomness in a distributed manner. + +First, we explain pairing-based cryptography (PBC), which has become quite popular, and is used in many modern consensus protocols or zero-knowledge proofs, such as zk-SNARKs. We'll then show how drand uses PBC for the randomness beacon generation phase for threshold Boneh-Lynn-Shacham (BLS) signatures. Finally, we'll discuss how drand links the generated threshold BLS signatures into a randomness chain. + +## Pairing-based Cryptography + +Pairing-based cryptography is based on bilinear groups `(𝔾1,𝔾2,𝔾𝑡)`, where `𝔾1`, `𝔾2`, and `𝔾𝑡` are cyclic groups of prime order `𝑝` with generators `𝑔1`, `𝑔2`, and `𝑔𝑡`, respectively, and a pairing operation `𝑒:𝔾1×𝔾2→𝔾𝑡` with these properties: + +- **Bilinearity:** `∀𝑎,𝑏∈ℤ∗𝑝,∀𝑃∈𝔾1,∀𝑄∈𝔾2,` we have `𝑒(𝑎𝑃,𝑏𝑄)=𝑒(𝑃,𝑄)𝑎𝑏` + +- **Non-degeneracy:** `𝑒≠1` +- **Computability:** There exists an efficient algorithm to compute `𝑒`. + drand currently uses the Barreto-Naehrig curve BN256. + +## BLS Signatures + +To generate publicly-verifiable, unbiasable, distributed randomness, drand utilizes threshold Boneh-Lynn-Shacham (BLS) signatures. First we'll describe regular BLS signatures and then the threshold variant. + +BLS signatures are short signatures that rely on bilinear pairings and consist only of a single element in `𝔾1`. They are deterministic in the sense they depend only on the message and the signer’s key, unlike other signature schemes, such as ECDSA, that require a fresh random value for each signed message to be secure. Put differently, any two BLS signatures on a given message produced with the same key are identical. In drand, we utilize this property to achieve unbiasability for randomness generation. + +The BLS signature scheme consists of the these sub-procedures. + +### Key Generation + +To generate a key pair, a signer first chooses a private key, `𝑥∈ℤ∗𝑝`, at random, and then computes the corresponding public key as `𝑋=𝑔𝑥2∈𝔾2`. + + + +### Signature Generation + +Let `𝐻:{0,1}∗→𝔾1` denote a cryptographic hash function that maps arbitrary bit strings to elements of `𝔾1`. To compute a BLS signature `𝜎` on a message `𝑚`, the signer simply computes `𝜎=𝑥𝐻(𝑚)∈𝔾1`. + + + +### Signature Verification + +To verify that a BLS signature `𝜎` on a message `𝑚` is valid, the verifier checks if `𝑒(𝐻(𝑚),𝑋)=𝑒(𝜎,𝑔2)` holds using the signer’s public key `𝑋`. + +It's easy to see that this equation holds for valid signatures since `𝑒(𝐻(𝑚),𝑋)=𝑒(𝐻(𝑚),𝑔𝑥2)=𝑒(𝐻(𝑚),𝑔2)𝑥=𝑒(𝑥𝐻(𝑚),𝑔2)=𝑒(𝜎,𝑔2)`. + +## Threshold BLS Signature + +The goal of a threshold signature scheme is to collectively compute a signature by combining individual partial signatures independently generated by the participants. A threshold BLS signature scheme has the following sub-procedures. + + +### Key Generation + +The `𝑛` participants execute a `𝑡-of-𝑛` DKG to setup a collective public key, `𝑆∈𝔾2`, and private key shares `𝑠𝑖∈ℤ∗𝑝` of the unknown collective private key, `𝑠`, as described above. + + + +### Partial Signature Generation + +To sign a message, `𝑚`, each `𝑖` uses their private key share, `𝑠𝑖`, to create a partial BLS signature, `𝜎𝑖=𝑠𝑖𝐻(𝑚)`. + + +### Partial Signature Verification + +To verify the correctness of a partial signature, `𝜎𝑖`, on `𝑚`, a verifier uses the public key share, `𝑆𝑖`, generated during the DKG, and verifies that `𝑒(𝐻(𝑚),𝑆𝑖)=𝑒(𝜎𝑖,𝑔2)` holds. + + + +### Signature Reconstruction + +To reconstruct the collective BLS signature, `𝜎` on `𝑚`, a verifier first gathers `𝑡` different and valid partial BLS signatures, `𝜎𝑖`, on `𝑚` followed by a Lagrange interpolation. + + + +### Signature Verification + +To verify a collective BLS signature, `𝜎`, a verifier simply checks that `𝑒(𝐻(𝑚),𝑆)=𝑒(𝜎,𝑔2)` holds, where `𝑆` is the collective public key. + + + +Thanks to the properties of Lagrange interpolation, the value of `𝜎` is independent of the subset of `𝑡` valid partial signatures, `𝜎𝑖`, chosen during signature reconstruction. Additionally, Lagrange interpolation also guarantees that no set of less than `𝑡` signers can predict or bias `𝜎`. + +In summary, a threshold BLS signature, `𝜎`, exhibits all properties required for publicly-verifiable, unbiasable, unpredictable, and distributed randomness. + + + +## Chained Randomness + + +The drand randomness beacon operates in discrete rounds, `𝑟`. In every round, drand producess a new random value using threshold BLS signatures linked together into a chain of randomness. To extend this chain of randomness, each drand participant, `𝑖`, creates in round `𝑟` the partial BLS signature, `𝜎𝑟𝑖` on the message `𝑚=𝐻(𝑟∥𝜎𝑟−1)` where, `𝜎𝑟−1` denotes the (full) BLS threshold signature from round `𝑟−1` and `𝐻`, a cryptographic hash function. + +Once at least `𝑡` participants have broadcasted their partial signatures, `𝜎𝑟𝑖`, on `𝑚`, anyone can recover the full BLS threshold signature, `𝜎𝑟` that corresponds to the random value of round `𝑟`. After this, drand nodes move to round `𝑟+1` and reiterate the process. + +For round `𝑟=0`, drand participants sign a seed fixed during drand setup. This process ensures that every new random value depends on all previously generated signatures. Since the signature is deterministic, there is also no possibility for an adversary forking the chain and presenting two distinct signatures `𝜎𝑟` and `𝜎′𝑟` in a given round `𝑟` to generate inconsistencies in the systems relying on public randomness. diff --git a/products/randomness-beacon/src/content/cryptographic-background/setup-phase.md b/products/randomness-beacon/src/content/cryptographic-background/setup-phase.md index 448e284585a0eca..98483219dd972e4 100644 --- a/products/randomness-beacon/src/content/cryptographic-background/setup-phase.md +++ b/products/randomness-beacon/src/content/cryptographic-background/setup-phase.md @@ -1,47 +1,34 @@ --- - -title: Setup Phase - - +order: 0 --- +# Setup Phase + In the drand setup phase, you create a collective private and public key pair shared among _𝑛_ participants. This is done through a `𝑡-of-𝑛` Distributed Key Generation (DKG) process and results in each participant recieving a copy of the collective public key plus a private key share of the collective private key — no individual node knows the collective **private** key. Each private key share can then be used to perform cryptographic threshold computations, such as generating threshold signatures, where at least `𝑡` contributions produced using the individual private key shares are required to successfully finish the collective operation. A DKG is performed in a fully distributed manner, avoiding any single points of failure. This is an overview of the different sub-components of the drand DKG implementation. - - - -## -Secret Sharing - +## Secret Sharing Secret sharing is an important technique many advanced threshold cryptography mechanisms rely on. Secret sharing allows you to split a secret value `𝑠` into `𝑛` shares `𝑠1,…,𝑠𝑛` so that `𝑠` can only be reconstructed if a threshold of `𝑡` shares is available. - -### -Shamir’s Secret Sharing (SSS) +## Shamir’s Secret Sharing (SSS) The SSS scheme is one of the most well-known and widely used secret sharing approaches, and a core component of drand. SSS works over an arbitrary finite field, but a simplistic approach uses the integers modulo `𝑝`, denoted by `ℤ𝑝`. Let `𝑠∈ℤ𝑝` denote the secret to share. -** -Share Distribution** +### Share Distribution To share `𝑠`, a dealer first creates a polynomial, `𝑞(𝑥)=𝑎0+𝑎1𝑥+⋯+𝑎𝑡−1𝑥𝑡−1` with `𝑎0=𝑠` and (random) `𝑎𝑖∈ℤ𝑝` for `𝑖=1,…,𝑡−1` and then creates one share 𝑠𝑖 for each participant 𝑖 by evaluating 𝑞(𝑥) at the integer 𝑖 and setting 𝑠𝑖=(𝑖,𝑞(𝑖)). - - -**Secret Reconstruction** +### Secret Reconstruction To recover the secret `𝑠`, collect at least `𝑡` shares, then uniquely reconstruct `𝑞(𝑥)` using Lagrange interpolation and obtain `𝑠` as `𝑠=𝑎0=𝑞(0)`. Note that you can use any subset of `𝑡-of-𝑛` shares to perform Lagrange interpolation and uniquely determine `𝑠`; however, having a subset of less than `𝑡` shares does not allow to learn anything about `𝑠`. -### - -Verifiable Secret Sharing +## Verifiable Secret Sharing SSS scheme assumes that the dealer is honest, but this may not always hold in practice. A Verifiable Secret Sharing (VSS) scheme protects against malicious dealers by enabling participants to verify that their shares are consistent with those dealt to other nodes, ensuring that the shared secret can be correctly reconstructed later. @@ -53,142 +40,34 @@ drand uses Feldman’s VSS scheme, an extension of SSS. Let `𝔾` denote a cycl -**Share Distribution** +### Share Distribution In addition to distributing shares of the secret to participants, the dealer also broadcasts commitments to the coefficients of the polynomial `𝑞(𝑥)` of the form `(𝐴0,𝐴1,…,𝐴𝑡−1)=(𝑔𝑠,𝑔𝑎1,…,𝑔𝑎𝑡−1)`. These commitments enable individual participants, `𝑖`, to verify that their share `𝑠𝑖=(𝑖,𝑞(𝑖))` is consistent with respect to the polynomial `𝑞(𝑥)` by checking that `𝑔𝑞(𝑖)=∏𝑡−1𝑗=0(𝐴𝑗)𝑖𝑗` holds. -**Secret Reconstruction** +### Secret Reconstruction The recovery of secret `𝑠` works the same as regular SSS, except that verified to be valid shares are used. -## Distributed Key Generation - (DKG) +## Distributed Key Generation (DKG) Although VSS schemes protect against a malicious dealer, the dealer still knows the secret. To create a collectively shared secret `𝑠` so no individual node gets any information about it, participants can use a DKG protocol. drand uses Pedersen’s DKG scheme, which runs `𝑛` instances of Feldman’s VSS in parallel and on top of additional verification steps. - -** -Share Distribution** +### Share Distribution Individual participants, `𝑖`, create a (random) secret, `𝑠𝑖∈ℤ𝑝`, and share it all participants using VSS, sending a share, `𝑠𝑖,𝑗` to each `𝑗` and broadcasts the list of commitments `(𝐴𝑖,0,𝐴𝑖,1,…,𝐴𝑖,𝑡−1)` to everyone. - - -**Share Verification** +### Share Verification `𝑗` verifies the shares received as prescribed by Feldman’s VSS scheme. If `𝑗` receives an invalid share, `𝑠𝑖,𝑗`, from `𝑖`, then `𝑗` broadcasts a complaint. `𝑖` must reveal the correct share `𝑠𝑖,𝑗` or they are considered an invalid dealer. - - -**Share Finalization** +### Share Finalization At the end of the protocol, the final share of `𝑖` is `𝑠𝑖=∑𝑗𝑠𝑗,𝑖` for all valid participants `𝑗` , that is, for all `𝑗`s not excluded during the verification phase. The collective public key associated with the valid shares can be computed as `𝑆=∑𝑗𝐴𝑗,0` for all valid `𝑗`s. - ->** -Note:** Even though the secret created using Pedersen’s DKG can be biased, it is safe to use for threshold signing as shown by Rabin et al. - - -In this section, we describe how to use this collective key pair to generate publicly-verifiable, unbiasable, and unpredictable randomness in a distributed manner. - -First, we explain pairing-based cryptography (PBC), which has become quite popular, and is used in many modern consensus protocols or zero-knowledge proofs, such as zk-SNARKs. We'll then show how drand uses PBC for the randomness beacon generation phase for threshold Boneh-Lynn-Shacham (BLS) signatures. Finally, we'll discuss how drand links the generated threshold BLS signatures into a randomness chain. - - - -# Pairing-based Cryptography - - -Pairing-based cryptography is based on bilinear groups `(𝔾1,𝔾2,𝔾𝑡)`, where `𝔾1`, `𝔾2`, and `𝔾𝑡` are cyclic groups of prime order `𝑝` with generators `𝑔1`, `𝑔2`, and `𝑔𝑡`, respectively, and a pairing operation `𝑒:𝔾1×𝔾2→𝔾𝑡` with these properties: - -- **Bilinearity:** `∀𝑎,𝑏∈ℤ∗𝑝,∀𝑃∈𝔾1,∀𝑄∈𝔾2,` we have `𝑒(𝑎𝑃,𝑏𝑄)=𝑒(𝑃,𝑄)𝑎𝑏` - -- **Non-degeneracy:** `𝑒≠1` -- **Computability:** There exists an efficient algorithm to compute `𝑒`. - drand currently uses the Barreto-Naehrig curve BN256. - - -# Randomness Generation - - -To generate publicly-verifiable, unbiasable, distributed randomness, drand utilizes threshold Boneh-Lynn-Shacham (BLS) signatures. First we'll describe regular BLS signatures and then the threshold variant. - -## BLS Signature - - - -BLS signatures are short signatures that rely on bilinear pairings and consist only of a single element in `𝔾1`. They are deterministic in the sense they depend only on the message and the signer’s key, unlike other signature schemes, such as ECDSA, that require a fresh random value for each signed message to be secure. Put differently, any two BLS signatures on a given message produced with the same key are identical. In drand, we utilize this property to achieve unbiasability for randomness generation. - -The BLS signature scheme consists of the these sub-procedures. - -**Key Generation** - -To generate a key pair, a signer first chooses a private key, `𝑥∈ℤ∗𝑝`, at random, and then computes the corresponding public key as `𝑋=𝑔𝑥2∈𝔾2`. - - - -**Signature Generation** - -Let `𝐻:{0,1}∗→𝔾1` denote a cryptographic hash function that maps arbitrary bit strings to elements of `𝔾1`. To compute a BLS signature `𝜎` on a message `𝑚`, the signer simply computes `𝜎=𝑥𝐻(𝑚)∈𝔾1`. - - - -**Signature Verification** - -To verify that a BLS signature `𝜎` on a message `𝑚` is valid, the verifier checks if `𝑒(𝐻(𝑚),𝑋)=𝑒(𝜎,𝑔2)` holds using the signer’s public key `𝑋`. - -It's easy to see that this equation holds for valid signatures since `𝑒(𝐻(𝑚),𝑋)=𝑒(𝐻(𝑚),𝑔𝑥2)=𝑒(𝐻(𝑚),𝑔2)𝑥=𝑒(𝑥𝐻(𝑚),𝑔2)=𝑒(𝜎,𝑔2)`. - -### Threshold BLS Signature - -The goal of a threshold signature scheme is to collectively compute a signature by combining individual partial signatures independently generated by the participants. A threshold BLS signature scheme has the following sub-procedures. - - -**Key Generation** - -The `𝑛` participants execute a `𝑡-of-𝑛` DKG to setup a collective public key, `𝑆∈𝔾2`, and private key shares `𝑠𝑖∈ℤ∗𝑝` of the unknown collective private key, `𝑠`, as described above. - - - -**Partial Signature Generation** - -To sign a message, `𝑚`, each `𝑖` uses their private key share, `𝑠𝑖`, to create a partial BLS signature, `𝜎𝑖=𝑠𝑖𝐻(𝑚)`. - - -**Partial Signature Verification** - -To verify the correctness of a partial signature, `𝜎𝑖`, on `𝑚`, a verifier uses the public key share, `𝑆𝑖`, generated during the DKG, and verifies that `𝑒(𝐻(𝑚),𝑆𝑖)=𝑒(𝜎𝑖,𝑔2)` holds. - - - -**Signature Reconstruction** - -To reconstruct the collective BLS signature, `𝜎` on `𝑚`, a verifier first gathers `𝑡` different and valid partial BLS signatures, `𝜎𝑖`, on `𝑚` followed by a Lagrange interpolation. - - - -**Signature Verification** - -To verify a collective BLS signature, `𝜎`, a verifier simply checks that `𝑒(𝐻(𝑚),𝑆)=𝑒(𝜎,𝑔2)` holds, where `𝑆` is the collective public key. - - - -Thanks to the properties of Lagrange interpolation, the value of `𝜎` is independent of the subset of `𝑡` valid partial signatures, `𝜎𝑖`, chosen during signature reconstruction. Additionally, Lagrange interpolation also guarantees that no set of less than `𝑡` signers can predict or bias `𝜎`. - -In summary, a threshold BLS signature, `𝜎`, exhibits all properties required for publicly-verifiable, unbiasable, unpredictable, and distributed randomness. - - - -## Chained Randomness - - -The drand randomness beacon operates in discrete rounds, `𝑟`. In every round, drand producess a new random value using threshold BLS signatures linked together into a chain of randomness. To extend this chain of randomness, each drand participant, `𝑖`, creates in round `𝑟` the partial BLS signature, `𝜎𝑟𝑖` on the message `𝑚=𝐻(𝑟∥𝜎𝑟−1)` where, `𝜎𝑟−1` denotes the (full) BLS threshold signature from round `𝑟−1` and `𝐻`, a cryptographic hash function. - -Once at least `𝑡` participants have broadcasted their partial signatures, `𝜎𝑟𝑖`, on `𝑚`, anyone can recover the full BLS threshold signature, `𝜎𝑟` that corresponds to the random value of round `𝑟`. After this, drand nodes move to round `𝑟+1` and reiterate the process. - -For round `𝑟=0`, drand participants sign a seed fixed during drand setup. This process ensures that every new random value depends on all previously generated signatures. Since the signature is deterministic, there is also no possibility for an adversary forking the chain and presenting two distinct signatures `𝜎𝑟` and `𝜎′𝑟` in a given round `𝑟` to generate inconsistencies in the systems relying on public randomness. \ No newline at end of file +**Note:** Even though the secret created using Pedersen’s DKG can be biased, it is safe to use for threshold signing as shown by Rabin et al. diff --git a/products/randomness-beacon/src/content/index.md b/products/randomness-beacon/src/content/index.md index 00d83664d448aca..73e123514ba1f1f 100644 --- a/products/randomness-beacon/src/content/index.md +++ b/products/randomness-beacon/src/content/index.md @@ -1,7 +1,11 @@ --- +title: Welcome order: 0 +type: overview --- -# Welcome +# Decentralized Verifiable Randomness Beacon -TODO... +Explore drand: a distributed service providing public randomness in an application-agnostic, secure, and efficient way + +Get started diff --git a/products/randomness-beacon/src/content/operator-guide/index.md b/products/randomness-beacon/src/content/operator-guide/index.md index 003b84474f4b19f..7043c1109a227e5 100644 --- a/products/randomness-beacon/src/content/operator-guide/index.md +++ b/products/randomness-beacon/src/content/operator-guide/index.md @@ -1,6 +1,7 @@ --- -title: Operator Guide -weight: 40 +order: 4 --- +# Operator Guide + For the most up-to-date operator documentation, please visit [drand.love/operator](https://drand.love/operator/). \ No newline at end of file diff --git a/products/randomness-beacon/src/content/user-guide/index.md b/products/randomness-beacon/src/content/user-guide/index.md index 0282ace2f0f0653..f50511c380980c0 100644 --- a/products/randomness-beacon/src/content/user-guide/index.md +++ b/products/randomness-beacon/src/content/user-guide/index.md @@ -1,7 +1,7 @@ --- - -title: User Guide -weight: 40 +order: 3 --- +# User Guide + For the most up-to-date user documentation, please visit [drand.love/developer](https://drand.love/developer/). \ No newline at end of file diff --git a/products/time-services/src/content/index.md b/products/time-services/src/content/index.md index 00d83664d448aca..743669dd2cce49e 100644 --- a/products/time-services/src/content/index.md +++ b/products/time-services/src/content/index.md @@ -1,7 +1,11 @@ --- +title: Welcome order: 0 +type: overview --- -# Welcome +# Cloudflare Time Services -TODO... +Learn more about Cloudflare's suite of time services. + +NTP   NTS   Roughtime diff --git a/products/time-services/src/content/ntp/index.md b/products/time-services/src/content/ntp/index.md index e09b34c0f980e8f..be1c3e4a455cf6e 100644 --- a/products/time-services/src/content/ntp/index.md +++ b/products/time-services/src/content/ntp/index.md @@ -1,8 +1,11 @@ --- -title: Network Time Protocol (NTP) -weight: 20 +order: 1 --- +# Network Time Protocol + [Network Time Protocol](https://tools.ietf.org/html/rfc1305) (NTP) is an Internet protocol designed to synchronize time between computer systems communicating over unreliable and variable-latency network paths. + NTP works by having a client send a query packet out to an NTP server that then responds with its clock time. The client then computes an estimate of the difference between its clock and the remote clock and attempts to compensate for network delay in this. NTP client queries multiple servers and implements algorithms to select the best estimate, and rejects clearly wrong answers. + NTP works by having a client send a query packet out to an NTP server that then responds with its clock time. The client then computes an estimate of the difference between its clock and the remote clock and attempts to compensate for network delay in this. NTP client queries multiple servers and implements algorithms to select the best estimate, and rejects clearly wrong answers. diff --git a/products/time-services/src/content/ntp/usage.md b/products/time-services/src/content/ntp/usage.md index 66fdb107bf4300b..f2553166879a992 100644 --- a/products/time-services/src/content/ntp/usage.md +++ b/products/time-services/src/content/ntp/usage.md @@ -1,8 +1,10 @@ --- -title: Cloudflare's Time Service -weight: 10 +title: User Guide +order: 0 --- +# Using Cloudflare's Time Service + Cloudflare offers a free public time service that allows you to use our anycast network of 180+ locations to synchronize time from our closest server. To use our NTP server, change the time configuration in your device to point to ```time.cloudflare.com```. We do not implement leap smearing: NTP includes a Leap Indicator field [spec](https://tools.ietf.org/html/rfc5905#section-7.3) and the kernel will apply the leap second correction at the appropriate time. This is the behavior servers diff --git a/products/time-services/src/content/nts/index.md b/products/time-services/src/content/nts/index.md index bb35d6fd3155b7f..c46ffb654fe119e 100644 --- a/products/time-services/src/content/nts/index.md +++ b/products/time-services/src/content/nts/index.md @@ -1,9 +1,9 @@ --- -title: Network Time Security (NTS) -weight: 40 +order: 2 --- -Network Time Security (NTS) provides cryptographic security for the client-server mode of the Network Time Protocol (NTP). This enables users to obtain time in an authenticated manner. +# Network Time Security -The NTS protocol is divided into two-phases. The first phase is the NTS key exchange that establishes the necessary key material between the NTP client and the server. This phase uses the Transport Layer Security (TLS) handshake and relies on the same public key infrastructure as the web. Once the keys are exchanged, the TLS channel is closed and the protocol enters the second phase. In this phase the results of that TLS handshake are used to authenticate NTP time synchronization packets via extension fields. For more information, read the [Internet draft](https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-19). +Network Time Security (NTS) provides cryptographic security for the client-server mode of the Network Time Protocol (NTP). This enables users to obtain time in an authenticated manner. +The NTS protocol is divided into two-phases. The first phase is the NTS key exchange that establishes the necessary key material between the NTP client and the server. This phase uses the Transport Layer Security (TLS) handshake and relies on the same public key infrastructure as the web. Once the keys are exchanged, the TLS channel is closed and the protocol enters the second phase. In this phase the results of that TLS handshake are used to authenticate NTP time synchronization packets via extension fields. For more information, read [RFC 8915](https://tools.ietf.org/html/rfc8915). diff --git a/products/time-services/src/content/nts/usage.md b/products/time-services/src/content/nts/usage.md index a9ec44701031e8c..cc7da841bde7485 100644 --- a/products/time-services/src/content/nts/usage.md +++ b/products/time-services/src/content/nts/usage.md @@ -1,19 +1,15 @@ --- -title: Secure Time Service -weight: 10 +title: User Guide +order: 0 --- -## NTS Client +# Using Cloudflare's Secure Time Service -You can use time.cloudflare.com as the source of time for all your devices today with NTP, while NTS clients are still under development. +[Chrony](https://chrony.tuxfamily.org/doc/devel/chrony.conf.html) and [NTPSec](https://www.ntpsec.org/) have support for NTS. Please read the relevant documentation for guidance on setting them up to point to our time service, `time.cloudflare.com`. -Cloudflare is working on an NTS client. If you would like to get updates about our NTS client development, email us at `time-services@cloudflare.com` to join the mailing list. - -There are currently a few organizations working on NTS Client [implementations](https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-19#page-30). [NTPsec](https://www.ntpsec.org/) is one of the organizations that includes experimental support for NTS; go to https://docs.ntpsec.org/latest/NTS-QuickStart.html for more information on NTPsec's implementation of an NTS client. - -## NTS Server - -Cloudflare's time service allows users to connect to our NTP server that supports Network Time Security, enabling users to obtain time in an authenticated manner. Anyone with an NTS supported client can obtain secure time by pointing their client to time.cloudflare.com:1234. Our NTS server supports both NTP and NTS, so while you can use any NTP client to get unauthenticated time, you can also use publicly available NTS clients to get secure time. - -Cloudflare’s time service will allow users to connect to our Network Time Protocol (NTP) server that supports Network Time Security (NTS), enabling users to obtain time in an authenticated manner. Anyone with an NTS supported client can obtain secure time by pointing their client to `time.cloudflare.com:1234`. +## Time Services Mailing List +If you would like to hear about the development of additional clients, +updates on our service, or would like to announce that your client +supports NTS, please email `time-services@cloudflare.com` to be added +to our distribution list. diff --git a/products/time-services/src/content/roughtime/about.md b/products/time-services/src/content/roughtime/about.md index e90384d99f3e7d1..25021ce98277a47 100644 --- a/products/time-services/src/content/roughtime/about.md +++ b/products/time-services/src/content/roughtime/about.md @@ -1,8 +1,9 @@ --- -title: The protocol -weight: 1 +order: 0 --- +# Roughtime Protocol + Endpoints on the Internet often synchronize their clocks using the Network Time Protocol ([NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol)). NTP provides precise synchronization, but is frequently deployed without a means of diff --git a/products/time-services/src/content/roughtime/index.md b/products/time-services/src/content/roughtime/index.md index 483d31cdaa53906..8dcb0e00276fa04 100644 --- a/products/time-services/src/content/roughtime/index.md +++ b/products/time-services/src/content/roughtime/index.md @@ -1,8 +1,9 @@ --- -title: Roughtime -weight: 60 +order: 3 --- +# Roughtime + [Roughtime](https://roughtime.googlesource.com/roughtime) is a simple, flexible, and secure authenticated time protocol developed by Google. This page introduces the key concepts of the protocol and demonstrates how to use Cloudflare's diff --git a/products/time-services/src/content/roughtime/recipes.md b/products/time-services/src/content/roughtime/recipes.md index 683cc2e04c5d9a6..edc968986f1ba49 100644 --- a/products/time-services/src/content/roughtime/recipes.md +++ b/products/time-services/src/content/roughtime/recipes.md @@ -1,8 +1,9 @@ --- -title: How to use it -weight: 2 +order: 2 --- +# Advanced Usage + This section describes a few ways you can use Roughtime to keep your clock in sync. These recipes will use Cloudflare's Go package, which is available on [GitHub](https://github.com/cloudflare/roughtime). It's based on Google's [Go diff --git a/products/time-services/src/content/roughtime/usage.md b/products/time-services/src/content/roughtime/usage.md index 5296d2d3264539e..f7956cd48f2fdda 100644 --- a/products/time-services/src/content/roughtime/usage.md +++ b/products/time-services/src/content/roughtime/usage.md @@ -1,7 +1,10 @@ --- -title: Cloudflare-Roughtime -weight: 10 +title: User Guide +order: 1 --- + +# Using Cloudflare's Roughtime Service + Our service can be reached at `roughtime.cloudflare.com:2002`. The domain resolves to an IP address in our [anycast IP range](https://www.cloudflare.com/learning/cdn/glossary/anycast-network/). You