Privacy Preserving Scalable Revocation

# Privacy Preserving Scalable Revocation ## 1. Introduction Revocation is one of the most difficult aspects of any credentialing system. PKI (Public Key Infrastructure) uses a "phone-home" system where clients check with the issuer whether the certificate is still valid (not-revoked), thus no privacy. Other proposals based on PIR (Privacy Information Retreival) require clients to download the entire \[[3](#rl2020), [4](#bl2024)\] (or a big enough subset) list of valid entries, disclose their unique index or identifier and check this against the list. While this approach allows the presenter to remain anonymous with the issuer, it does not achieve privacy with the verifier. Some accumulator based approaches require publishing updates when entries are added and removed which requires clients to download large lists to perform local updates and stay in sync or "phone-home" to the revocation manager. Neither approach is scalable and privacy preserving. Downloading large lists penalizes users who do not stay constantly current since they must download all changes since their last update, leaking how long they've been offline, and in some cases is not cryptographically secure (see \[[1](#allosaur)\] for these details). Other accumulator based schemes have been proposed \[[5](#indy)\] that use static lists created at initialization time but again require downloading large amounts of data which can cause issues when checking for current status. The most common non-privacy approach requires users to "phone-home". The "phone-home" concept is defined as the holder revealing their revocation claim to the issuing party (or intermediary) to determine their revocation status. Either the holder does this directly or the verifier forwards the claim to the issuing party. In this manner, the revocation manager either returns another credential with the current status or gives the status directly. The additional credential can be good for a single presentation, includes date times like expires after or at, or some other method. This is also not privacy preserving as the revocation manager and/or others learn unintended information about the presenter. In many cases the revocation claim being checked is a unique value. This value can be used to track the presenter across uses which is undesirable much like a tracking cookie. To be both *scalable* and *privacy-preserving*, the revocation scheme must meet the following requirements: 1. The number of issued credentials must not impact the time to check revocation status i.e. must remain constant for the verifier. 1. Client updates must not depend on the time since their last update. 1. Updating revocation status must not leak either the precise client requesting the update. ### 1.1 Our Contribution This document presents a revocation scheme that ensures privacy across various scenarios while being highly scalable, capable of handling millions or even billions of users. This method employs a pairing-based cryptographic accumulator, which, unlike previous approaches, does not necessitate updates from credential holders when new entries are added; updates are only required when elements are removed or revoked. Additionally, this scheme does not compel any party to download the entire set of entries for updates or revocation checks, nor does it penalize clients for not remaining up-to-date. The holder uses a similar method to "phone-home" but preserves privacy by not revealing their revocation claim. The only relevant data required for revocation checks is contained within a small, authenticated registry. This registry leaks nothing about the secret key, the elements in the set, or the information about values added/removed. In addition to working in the single-server case, our scheme enables threshold-based key management, signing, updates, and removals through a decentralized or distributed service (multi-server case). As all accumulator operations utilize BLS signatures, communication between distributed nodes is significantly reduced, often eliminating the need for it altogether in most scenarios. In the multi-server case, any non-compliant server e.g. a server that deviates from any protocol, can be detected by the user and system and thus can be dealt with accordingly (blaming, removal, etc). This revocation scheme may be combined with any other cryptographic signature supported by verifiable credentials. ### 1.2 What this doesn't solve **Connection anonymity** Without anonymous connections (e.g., the user connects from the same IP address each time), witness updates are only pseudonymous, even with a perfectly blind protocol. **Last update** This protocol still leaks when the user last updated since the revocation manager needs to include all changes since that time. However, this is the only information leaked about the user. **Collusion** If the revocation manager colludes with a verifier, they can break anonymity by revoking a user’s credentials and checking whether they are still able to verify. This is unavoidable in a collision-free accumulator. Unlike other anonymity-breaking collusions that we try to avoid, this attack is publicly logged because accumulator values and changes are public. An audit would notice the spurious revocation of a user’s credentials. This document focuses on technical aspects, but any real implementation of an anonymous accumulator must include a policy on what should be done in this case. **Compromise** The revocation witness should receive similar protections like a secret signing key. If compromised, the witness grants the adversary the ability to prove its anonymous revocation status. Thus revocation status' should only be completed as part of a verifiable credential presentation. ## 2. Preliminaries ### 2.1 Notation We let $\ell$ denote the security parameter, for this document is 128-bits. Let $||$ represent the byte cocatenation of the left and right hand side values. All hash functions are cryptographically secure hash functions unless otherwise noted. All points are serialized in compressed canonical format--big endian ordered. Scalars are likewise big endian ordered. For simplicity, we assume the [BLS12-381](#bls12381) curve but any pairing friendly curve should suffice, but should meet the security parameters. Throughout the paper, we will deal with protocols between an ordered set of $n$ parties, $P_1,\ldots, P_n$. We let $\mathcal{H}$ be the set of indices of honest parties, and $\mathcal{C}$ the set of indices of corrupt ones. The symbol $[m]$ indicates the set $\{0,1,2,\ldots,m−1\}$. Uppercase letters denote points in G1 and G2. Lowercase letters represent curve scalars. The symbol [[x]] denotes the linear shares of *x* where $x = x_1 + x_2 + \cdots + x_n$. P is the generator point for the field G1 and $\widetilde{P}$ is the generator for G2. G1 points are 48 bytes serialized, G2 points are 96 points serialized, and Scalars are 32 bytes serialized. ### 2.2 Functions We denote all mathematical operations on points using the color blue and scalars as black. *HZq(b, d)$\xrightarrow{}$ s* hashes the byte sequence *b* with domain tag *d* and outputs the scalar *s*. *HG1(b, d) $\xrightarrow{}$ P* hashes the byte sequence *b* with domain tag *d* and outputs point P in G1. *EcMul(P, s) $\xrightarrow{}$ P'* computes elliptic curve scalar multiplication on point *P* with scalar *s* s.t. P' = *sP*. *EcAdd(P, Q) $\xrightarrow{}$ P'* computes elliptic curve point addition s.t. P' = P + Q. *EcSub(P, Q) $\xrightarrow{}$ P'* computes elliptic curve point addition s.t. P' = P - Q. *EcNeg(Q) $\xrightarrow{}$ Q'* computes elliptic curve point negation s.t. Q' = -Q. *EcPairing(P, Q) $\xrightarrow{}$ w* computes the type-3 pairing using G1 point P and G2 point Q and outputs w in Gt. *ScalarAdd(s1, s2) $\xrightarrow{}$ s3* computes scalar field addition s.t. s3 = s1 + s2. *ScalarSub(s1, s2) $\xrightarrow{}$ s3* computes scalar field subtraction s.t. s3 = s1 - s2. *ScalarNeg(s) $\xrightarrow{}$ s'* computes scalar field negation s.t. s' = -s. *ScalarInv(s) $\xrightarrow{}$ s'* computes scalar field invert s.t. s' = $\frac{1}{s}$ also s-1. *ScalarGen() $\xrightarrow{}$ s* generates a uniformly random scalar *s*. *ShamirShare(x, t, n) $\xrightarrow{}$ [[x]]* computes a *t*-out-of-*n* sharing of *x* by dividing it into multiple shares as \[\[x\]\]. *ShamirRec(\[\[x\]\]) $\xrightarrow{}$ x* reconstructs secret *x* from at least *t* shares \[\[x\]\]. *KeyGen() $\xrightarrow{}$ {x, $\widetilde{X}$}* generates a key pair. This can be done by a single party or collection using a DKG (distributed key generation) algorithm. The output is secret key *x* and verification key $\widetilde{X}$ = *x* *$\widetilde{P}$ *BlsSign(x, m, d)$\xrightarrow{} \sigma$* generates a BLS signature $\sigma$ using secret key *x* over the message *m* with optional domain tag *d* with steps: 1. A = HG1(m, d) 2. $\sigma$ = xA *BlsSignShare(\[\[x\]\], m)$\xrightarrow{}$\[\[$\sigma$\]\]* generates a BLS signature share $[[\sigma]]$ using secret share \[\[x\]\] over the message *m* with steps 1. A = HG1(m, d) 2. \[\[$\sigma$\]\] = \[\[x\]\]A *SigShareCombine(\[\[$\sigma$\]\])$\xrightarrow{} \sigma$* constructs the signature $\sigma$ with steps: 1. $\sigma$ = ShamirRec(\[\[$\sigma$\]\]) *SigVerify($\sigma$, X, m, d) $\xrightarrow{} \bot/\top$* validates whether signature $\sigma$ using verification key *X* is over *m* and optional domain tag *d*. *AccumGen()$\xrightarrow{}$ V* generates a new accumulator *V* with no entries. *WitnessGen(m, x, V)$\xrightarrow{}$ W* creates an accumulator witness over message *m* with secret key *x* and accumulator *V* with steps: 1. k = m + x 1. e = $\frac{1}{k}$ 1. W = eV *WitnessCheck(m, W, V, Q) $\xrightarrow{} \bot/\top$* verifies a witness *W* for message *m* is valid for accumulator *V* with public key *Q* with steps: 1. EcPairing(W, mG2 + Q) * EcPairing(V, -G2) == 1 *WitnessGenShare(m, [[x]], V)$\xrightarrow{}$ W* creates an accumulator witness *W* over message *m* with secret key share *[[x]]* and accumulator *V* with the following steps: 1. k = [[x]] + m 1. e = $\frac{1}{k}$ 1. W = eV *ClientWitnessUpdate(m, t, $\mathcal{H}$) $\xrightarrow{}$ {[p], [[m]]}* creates a witness update request for *m* using a *t*-out-of-*n* sharing with steps: 1. \[\[m\]\] = ShamirShare(m, t, n) 2. {p_i, m_i} for each $\mathcal{H}$ *ManagerWitnessUpdate(p_i, m_i, [[x]]) $\xrightarrow{} \delta$* creates a witness update $\delta$ from the request data *p_i, m_i* using [[x]]. TODO: Add steps *ClientWitnessApply(\[\[$\delta$\]\], W, m) $\xrightarrow{}$ W'* updates the witness *W* using valid update shares \[\[$\delta$\]\] and element *m*. TODO: Add steps from paper *Revoke(m, x, V) $\xrightarrow{}$ V'* removes the message *m* from the accumulator *V* using secret key *x* with steps: 1. k = m + x 2. e = $\frac{1}{k}$ 3. V' = eV *ProofParams(b, d) $\xrightarrow{} \omega$* generates the ZKP (zero-knowledge proof) parameters $\omega$ from byte sequence *b* and domain tag *d* with steps: 1. X = HG1(1, b, d) 1. Y = HG1(2, b, d) 1. Z = HG1(3, b, d) 1. $\omega$ = {X, Y, Z} *ProofGen(m, y, W, V, $\widetilde{X}$, b, d, $\mathcal{T}$) $\xrightarrow{} \pi$* generates a ZKP using proof parameters $\omega$ with message *m*, a blinding scalar *y*, witness *W*, against accumulator *V* and public key *Q* with a nonce byte sequence *b*, domain tag *d*, and transcript $\mathcal{T}$ with steps: 1. $\omega$ = ProofParams(V, $\widetilde{X}$, b, d) 1. {X, Y, Z} = $\omega$ 1. $\mathcal{T}$.Add(P, $\widetilde{P}$, $\widetilde{X}$, V, X, Y, Z) 1. $\eta, \rho, r_{\eta}, r_{\rho}, r_{\delta_\eta}, r_{\delta_{\rho}}$ = ScalarGen() x 6 1. Ec = W + ($\eta$ + $\rho$)Z 1. T$\eta$ = $\eta$X 1. T$\rho$ = $\rho$Y 1. $\delta_{\eta}$ = $\eta$m 1. $\delta_{\rho}$ = $\rho$m 1. R$\eta$ = $r_{\eta}$X 1. R$\rho$ = $r_{\rho}$Y 1. R$\delta_{\eta}$ = yT$\eta$ - $r_{\delta_{\eta}}$X 1. R$\delta_{\rho}$ = yT$\rho$ - $r_{\delta_{\rho}}$Y 1. e = -($r_{\delta_{\eta}}$ + $r_{\delta_{\rho}}$) 1. l = EcPairing(yEc + eZ, -$\widetilde{P}$) 1. f = -($r_{\eta}$ + $r_{\rho}$) 1. r = EcPairing(fZ, $\widetilde{X}$) 1. re = lr 1. $\mathcal{T}$.Add(Ec, T$\eta$, T$\rho$, re, R$\eta$, R$\rho$, R$\delta_{\eta}$, R$\delta_{\rho}$, b, d) 1. c = $\mathcal{T}$.Challenge() 1. sm = y - cm 1. s$\eta$ = $r_\eta$ - c$\eta$ 1. s$\rho$ = $r_\rho$ - c$\rho$ 1. s$\delta_{\eta}$ = $r_{\delta_{\eta}}$ - c$\delta_{\eta}$ 1. s$\delta_{\rho}$ = $r_{\delta_{\rho}}$ - c$\delta_{\rho}$ 1. $\pi$ = {Ec, T$\eta$, T$\rho$, sm, s$\eta$, s$\rho$, s$\delta_{\eta}$, s$\delta_{\rho}$, c} The ZKP is only 304 bytes and takes 3ms to generate on a modern smartphone. *ProofVerify($\pi$, V, $\widetilde{X}$, b, d, $\mathcal{T}$)$\xrightarrow{} \bot/\top$* verifies proof $\pi$ using the accumulator *V*, the public key $\widetilde{X}$, the nonce *b*, domain tag *d*, and transcript $\mathcal{T}$ with steps: 1. {Ec, T$\eta$, T$\rho$, sm, s$\eta$, s$\rho$, s$\delta_{\eta}$, s$\delta_{\rho}$, c} = $\pi$ 1. $\omega$ = ProofParams(V, $\widetilde{X}$, b, d) 1. {X, Y, Z} = $\omega$ 1. $\mathcal{T}$.Add(P, $\widetilde{P}$, $\widetilde{X}$, V, X, Y, Z) 1. R$\eta$ = s$\eta$X - cT$\eta$ 1. R$\rho$ = s$\rho$Y - cT$\rho$ 1. R$\delta_{\eta}$ = smT$\eta$ - s$\delta_{\eta}$Y 1. R$\delta_{\rho}$ = smT$\rho$ - s$\delta_{\rho}$Y 1. re = EcPairing(smEc - (s$\delta_{\eta}$ + s$\delta_{\rho}$)Z - cV, $\widetilde{P}$) 1. re = re * EcPairing(cEc - (s$\eta$ + s$\rho$)Z, $\widetilde{X}$)) 1. $\mathcal{T}$.Add(Ec, T$\eta$, T$\rho$, re, R$\eta$, R$\rho$, R$\delta_{\eta}$, R$\delta_{\rho}$, b, d) 1. cv = $\mathcal{T}$.Challenge() 1. c == cv Verification takes roughly 5ms on modern smart phones. ### 2.2.1 Domain tags All hash functions use domain separation tags denoted as *d*. These are constants and defined as follows: 1. BLS signatures: `BLS_SIG_BLS12381G1_XMD:SHA-256_SSWU_RO_POP_`. 1. Accumulator elements: `ALLOSAUR_ELEMENT_BLS12381G1_XMD:SHA-256_RO_` 1. Proof Parameters: `ALLOSAUR_PROOF_PARAMS_BLS12381G1_XMD:SHA-256_SSWU_RO_` ## 3. Revocation Scheme The accumulator is tied to the keys, thus if the keys are compromised or revoked all entries in the accumulator are also. Setting $V = P$ revokes all entries. Accumulator elements ultimitely are scalar values. Elements can be generated randomly or computed using HZq(). From hereon, this distinction is irrelevant. For example, the issuer may use UUIDs and use HZq(UUID). This proposal is agnostic to the method chosen but assumes all functions use the scalar values. This scheme supports separating the roles revocation manager and issuer. The Issuer manages the accumulator elements while the revocation manager handles the accumulator keys. They are allowed to be the same entity with no inherint security risk in this setup. For the sake of simplicity this document assumes them to be the same party unless otherwise stated. ### 3.1 Setup The issuer calls *KeyGen* to create BLS keys (*y*, $\widetilde{Y}$) and the accumulator keys (*x*, $\widetilde{X}$). Next *AccumGen* creates the accumulator *V*. The values (V, $\widetilde{X}$, $\widetilde{Y}$) are made public while (*x*, *y*) are retained. The identifier for this is computed using *BlsSign(x, $\widetilde{X} || \widetilde{Y}$, d) $\xrightarrow{} \sigma$* with *d*=`BLS_POP_BLS12381G1_XMD:SHA-256_SSWU_RO_POP_`. All values are hex lower case encoded with no `0x` prefix. The registry contains the following information. For example purposes only ```json { "identifier": "a3f7b1e89c0d24576a3f7b1e89c0d24576a3f7b1e89c0d24576a3f7b1e89c0d24576a3f7b1e89c0d24576a3f7b1e89c0d24576", "signature_verification_key": "d8a2f7b1e89c0d24576a3f7b1e89c0d24576a3f7b1e89c0d24576a3f7b1e89c0d24576a3f7b1e89c0d24576a3f7b1e89c0d24576", "accumulator_verification_key": "9e2c5f8a1b3d674ef9e2c5f8a1b3d674ef9e2c5f8a1b3d674ef9e2c5f8a1b3d674ef9e2c5f8a1b3d674ef9e2c5f8a1b3d674ef9e2c5f8a1b3d674e", "accumulator": "9e2c5f8a1b3d674ef9e2c5f8a1b3d674ef9e2c5f8a1b3d674ef9e2c5f8a1b3d674ef9e2c5f8a1b3d674ef9e2c5f8a1b3d674e", } ``` The registry MUST be signed when published using the BLS key. The identifier can be verified using *BlsVerify* since all information is included. Other optional information could include timestamps for last-update, issued-at, created-at, next-update-at, etc. These timestamps, though not required for presentation privacy, help verifiers understand how fresh the registry is and how often they can expect updates. All timestamps must use strings encoded in [RFC3339](https://datatracker.ietf.org/doc/html/rfc3339) format with seconds precision. More precise seconds are recommended but not required as they represent a unique timestamp. The registry is meant to be human readable when published. However, binary formats are also acceptable when readability is not required such as [cbor](https://cbor.io/), [bare](https://datatracker.ietf.org/doc/draft-devault-bare/), [msgpack](https://msgpack.org/index.html), [protobufs](https://protobuf.dev/), [flatbuffers](https://flatbuffers.dev/), and [postcard](https://postcard.jamesmunns.com/). Implementors are not required to support binary encodings but it is RECOMMENDED to support at least one human readable format. The only value that MUST be published on update is `accumulator`. The keys MUST also not change. If they do the accumulator is considered invalid. ## 4. Process When a credential is signed, the issuer inserts a revocation claim into the credential. The issuer calls *WitnessGen* using the revocation claim returns the witness, revocation claim, and a reference the accumulator registry, (or the value itself) to the holder. The holder verifies that the witness is valid using *WitnessCheck*. When the *holder* wants to present to a relying party *verifier*, a few options are available for them to check revocation status and if necessary perform a witness update: First the holder needs to determine if they are out of date by 1. Retrieving the most recent registry themselves or 2. The verifier sends the registry they expect the holder to prove against The holder checks the registries validity using the public keys then determines if the accumulator value to which their witness is valid is the same in the registry. If positive, the holder can immediately generate their proofs. Otherwise they update their witness using one of the following methods: #### Method 1 - Holder only 1. Call *ClientWitnessUpdate* on their revocation claim and send those shares one at a time in separate requests to the issuer. These request can be parallelized but the point is the issuer must not know its for the same holder. Dummy values can also be sent. The issuer cannot determine whether the received values are fake or real. The issuer might have multiple endpoints to which these shares can be sent if using a threshold setup. This is similar to PIR. 1. The issuer's endpoints use *ManagerWitnessUpdate* to compute their values and return the results to the holder. The issuer's endpoints do not need to communicate with each other. 1. The holder discards and results related to dummy values and once *t* real results have been returned calls *ClientWitnessApply*. 1. Call *WitnessCheck* to verify the update witness. #### Method 2 - Update Proxy Because witness updates are anonymous to the issuer, a semi-trusted proxy party could be used instead of the holder communicating directly to the issuer, such as the verifier. The same process is used as Method 1 except the verifier forwards the request to the issuer. This approach hides the holder involvement like IP addresses among other data. #### Revoking all credentials To revoke all credentials, set `accumulator` to P. To allow all credentials (such as testing only), set `accumulator` to the point at infinity $1_{G1}$. #### Claim management Revocation claims are not required to be published and in fact SHOULD not be made known. The issuer should keep these private except to the holders to which they belong. These values can be stored in a database or lookup table. The claims can be revoked in batches when required. Revoked claims should be maintained in a list until the accumulator is retired. #### Security considerations The verifier just like the issuer cannot determine from looking at the request, what is the threshold and whether the request share is real or a dummy. The verifier can manipulate the requests but this is no different than the issuer or any other maliciously acting party. Worse case, the issuer or verifier acquires all valid shares and reconstructs the revocation claim, this does not grant them the ability to impersonate the holder or track them since revocation claims are never disclosed during presentation due to ZKPs and to generate a valid ZKP, the party must also possess a valid witness. The witness can not be implied or predicted from the accumulator, the claim, or the verification key. More information can be found in \[[1](#allosaur)\]. In \[[1](#allosaur)\], it is discussed that a malicious holder might try to update even if they've been revoked. \[[1](#allosaur)\] shows using security proofs that once they update when their claim is removed from the accumulator, their witness is now invalidated, so a malicious holder has no incentive to update. But, if issuer never publishes which claims have been removed, the holder doesn't even know if they have been revoked. Another scenario could be a malicious party trying to impersonate the holder as described previously by requesting an update since the issuer doesn't know who the party is. Again, in \[[1](#allosaur)\], it is shown that unless the requestor already has a valid witness to start, the returned result doesn't help them at all. Ultimately, an adversary cannot successfully fool the protocol without possessing a valid claim and and witness. #### Verification The verifier sets the freshness requirements for the accumulator based on the risk level; more critical situations may demand an accumulator no older than 24 hours, while less critical ones may accept one up to a week old. The verifier has the discretion to choose which accumulator values to accept for a revocation presentation. If a holder can demonstrate that they are not revoked, the verifier is obliged to accept this proof. The verifier's requirement is limited to using the `accumulator_verification_key` and `accumulator` during presentation verification, which only involves downloading 128 bytes of data. However, to ensure these values are authentic, the verifier should also download and verify the entire registry against its signature. Importantly, the size of the registry remains constant, unaffected by the number of issued or revoked claims. Consequently, both the data volume reviewed by the verifier and the data published by the issuer remain consistent. Additionally, the time it takes for holders to compute a ZKP does not change, as the accumulator value size is constant. ## Use with Credential Signatures This revocation scheme is not limited to pairing based signature schemes such as BBS or (PS) Pointcheval Sanders and may be combined with Schnorr based signatures like Ed25519 or Taproot. ECDSA signatures are supported but not recommended since they do not support privacy by default where as Schnorr based signatures support simple discrete log based proof combinations. The algorithms in Appendix K of \[[1](#allosaur)\] show how this can be accomplished and are included below. ### Other notes Our scheme does not require any blockchain but certainly works in that case and might even be ideal since the registry size is quite small. It is recommended to use the blockchain signature instead of BLS in that case. #### BBS or PS signatures TODO: Add #### Schnorr-based (Ed25519) or Taproot TODO: Add ## Test Vectors TODO: Add ## References 1. <a name="allosaur"></a>[ALLOSAUR: Accumulator with Low-Latency Oblivious Sublinear Anonymous credential Updates with Revocations](https://eprint.iacr.org/2022/1362), Samuel Jaques, Michael Lodder, and Hart Montgomery, 2022 1. [Dynamic Universal Accumulator with Batch Update over Bilinear Groups](https://eprint.iacr.org/2020/777), Giuseppe Vitto and Alex Biryukov, 2020 1. <a name="rl2020"></a>[Revocation List 2020](https://w3c-ccg.github.io/vc-status-rl-2020/), Manu Sporny and David Longley 1. <a name="bl2024"></a>[Bitstring Status List v1.0](https://www.w3.org/TR/vc-bitstring-status-list/) 1. <a name="indy"></a>[Indy Credential Revocation](https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/concepts/revocation/cred-revocation.html) 1. <a name="bls12381"></a>[BLS For the Rest of Us](https://hackmd.io/@benjaminion/bls12-381), Ben Edgington, 2023

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.