Zhuang's Diary

SD-JWT:

https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
https://github.com/eu-digital-identity-wallet/eudi-lib-jvm-sdjwt-kt

算法实现:

1. 数据封装:
   • 数据被封装在JWT中，包含需要选择性披露的声明（claims）。
   • 每个声明都可以独立加密或哈希处理。
2. Merkle树结构:
   • 为所有声明构建一个Merkle树，每个叶子节点代表一个哈希后的声明。
   • 通过哈希值的组合，形成父节点，直到生成一个根哈希值（root hash）。
3. 签名:
   • 使用私钥对整个JWT（包括Merkle树的根哈希值）进行签名。
   • 签名确保数据的完整性和真实性。
4. 选择性披露:
   • 用户可以选择性地披露特定的声明，并提供相应的Merkle证明（包含所需的兄弟节点哈希）。
   • 验证者使用Merkle证明验证特定声明是否属于原始数据。
     关键技术:

• JWT
• Merkle树
• 数字签名

BBS Signature:

算法实现:

1. 签名生成:
   • 生成密钥对（私钥和公钥）。
   • 使用私钥对消息进行签名，生成一个签名值。
2. 选择性披露:
   • 允许用户选择性披露部分数据，并生成零知识证明（ZKP），证明所披露的数据是原始数据的一部分。
3. 验证:
   • 验证者使用公钥和零知识证明，验证所披露的数据的真实性和完整性。
   • 确保签名和数据未被篡改。
     关键技术:

• 零知识证明
• 数字签名
• 椭圆曲线密码学

BBS+ Signature:

https://github.com/mattrglobal/bbs-signatures
Org BBS+ Signature algorithm PPT: https://datatracker.ietf.org/meeting/114/materials/slides-114-cfrg-bbs-signature-scheme-pdf-00
https://github.com/decentralized-identity/bbs-signature
https://github.com/microsoft/bbs-node-reference

算法实现:

1. 优化签名生成:
   • 基于BBS签名算法，增加了对复杂电路和多项声明的支持。
   • 使用私钥对多个声明进行签名，生成一个增强的签名值。
2. 增强的选择性披露:
   • 允许用户更高效地选择性披露部分数据，并生成更高效的零知识证明。
   • 增强了对复杂数据结构和大规模应用的支持。
3. 高效验证:
   • 验证者使用公钥和优化后的零知识证明，验证所披露的数据的真实性和完整性。
   • 验证过程经过优化，提高了性能和效率。
     关键技术:

• 优化的零知识证明
• 数字签名
• 高效验证算法

PolygonID:

https://github.com/0xPolygonID/issuer-node

zkSNARK

https://github.com/iden3/snarkjs (Groth16, PLONK, FFLONK三种算法可选)

主要步骤:

1. 设置（Setup）:
   • 生成一组公共参数（公共参考字符串CRS），包括两个部分：证明密钥（proving key）和验证密钥（verifying key）。公共参数由一个复杂的数学过程生成，通常基于椭圆曲线和配对。
   • 这个过程涉及一个可信的第三方，确保公共参数的安全生成。
2. 证明生成（Proving）:
   • 证明者使用具体的输入（满足某个电路或逻辑条件）和证明密钥生成一个简洁的证明（Proof）。
   • 该证明由少量的群元素组成，可以非常高效地传输和存储。
3. 验证（Verification）:
   • 验证者使用验证密钥验证证明的有效性，确保输入满足声明的逻辑条件。
   • 通过检查一个简单的数学等式，只需检查少量计算，验证过程快速且高效。

SD-JWT（Self-issued, Decentralized JWT）、BBS+ Signature（BlsBBSIG-based Signature）和 PolygonID 是与去中心化身份（DID）相关的不同技术或概念。为了比较它们在DID应用中的适用性，我们可以考虑几个关键维度，如安全性、隐私性、易用性、互操作性和可扩展性。以下是对这些技术的比较，以及它们在DID应用中的评级：

Groth16, PLONK 和 FFLONK 在PolygonID中的应用

https://www.youtube.com/watch?v=V2UJ9xzbJGs&t=10633s
https://www.bis.org/about/bisih/topics/cbdc/mcbdc_bridge.htm
BIS Innovation Summit 2024: Navigating rapid innovation (day 1)中，mbridge (showcase)中讲到，其项目的privacy中使用了 Pseudonymization algorithm。下面针对 Pseudonymization 展开详细讲述。

1. https://github.com/kiprotect/kodex

假名化（Pseudonymization）算法可以分为几个类别，包括可逆和不可逆方法，以及结构保持和格式保持方法。以下是网页中提到的一些关键点：

假名化技术（PET）

• 假名化是一种隐私增强技术，它将数据点中的直接或间接标识符替换为其他“假名”值，从而保护数据所属个体的身份。

假名化方法分类

• 可逆假名化方法：允许数据去假名化，即利用额外数据（如加密密钥或映射表）从假名恢复到原始标识符。
• 不可逆假名化方法：不允许从假名恢复到原始标识符。
• 确定性假名化方法：对同一个标识符应用时总是创建相同的假名。
• 非确定性方法：即使多次应用到同一个标识符，也会生成随机假名。
• 结构保持假名化方法：保持标识符的特定内部结构。
• 格式保持假名化方法：保持数据的原始格式。

可逆方法

Kodex支持基于格式保持加密的可逆假名化方法。使用原始密钥可以解密/去假名化生成的假名。例如，merengue假名化方法可以操作任意二进制数据，并生成二进制假名，此外还可以保持数据的前缀结构。

结构保持方法

基于merengue方法，Kodex提供了多种结构保持假名化方法，可以操作如时间戳、IP地址和数字等数据类型。这些方法保持原始数据的格式，并且也可以保持结构信息。

不可逆方法

Kodex也支持不可逆假名化方法，特别是基于密钥哈希的消息认证码（HMAC）的假名化，以及无密钥哈希的假名化（强烈不推荐）。例如，以下动作生成基于HMAC的假名：

假名化方法的配置参数

• merengue方法接受一个encode参数，指定结果字节字符串的编码。目前唯一可能的值（也是默认值）是base64。
• structured方法接受以下参数：
  • preserve-prefixes：如果为_true_，将保留结构化数据值的前缀。例如，使用_date_格式时，具有共同前缀的日期（例如相同的年和月）将映射到也共享相同长度前缀的假名。默认为_false_。
  • type：指定要假名化的数据类型。必须是ip、date、integer、ipv4或ipv6之一。
  • type-params：根据所选类型指定额外的类型参数。目前，只有integer类型需要强制的min和max类型参数，以指定其范围。
  • format：指定要假名化的数据的类型依赖格式（如果适用）。目前，只有date类型支持format参数。

2. https://github.com/aws-samples/pseudonymization-service

示例中，pseudonymization-service 是利用 AES+gcm+siv实现的。
AES/GCM/SIV 是一种基于 AES（高级加密标准）的加密模式，它结合了 Galois/Counter Mode（GCM）和 SIV（Synthetic Initialization Vector）的特性。

AES/GCM/SIV 的关键特性：

1. AES (Advanced Encryption Standard): AES 是一种广泛使用的对称加密算法，它以128位的块大小对数据进行加密。
2. GCM (Galois/Counter Mode): GCM 是一种认证加密模式，它不仅提供加密，还提供数据完整性校验和重放攻击保护。GCM 使用一个nonce（一次性密码），也称为初始化向量（IV），以及一个附加的认证标签（tag）来确保数据的完整性和真实性。
3. SIV (Synthetic Initialization Vector): SIV 是一种模式，它允许使用相同的加密密钥对多个消息进行加密，而不需要为每个消息生成新的随机IV。这在某些场景下非常有用，比如当需要加密大量数据或者需要从相同的密钥派生多个IV时。

EncryptionAESGCMSIV 类：

在 Java 中，EncryptionAESGCMSIV 类可能是用来实现 AES/GCM/SIV 加密模式的一个类。这个类可能包含以下功能：

• 加密数据：使用 AES/GCM/SIV 算法对输入数据进行加密，并生成密文和认证标签。
• 解密数据：使用相同的加密密钥和正确的认证标签对密文进行解密，恢复原始数据。
• 生成和验证认证标签：在加密过程中生成认证标签，并在解密过程中验证这个标签以确保数据的完整性和真实性。

使用场景：

AES/GCM/SIV 算法适用于需要高安全性和效率的场景，特别是在以下情况：

• 数据需要在不安全的通道上传输，比如互联网。
• 需要确保数据的完整性和防止篡改。
• 需要抵抗重放攻击，即攻击者不能简单地重放之前捕获的加密数据。

注意事项：

使用任何加密算法时，都需要遵循最佳实践，比如：

• 使用强密钥。
• 密钥管理应该安全，避免泄露。
• 使用合适的随机数生成器来生成 IV 或 nonce。

https://www.bis.org/events/bis_innovation_summit_2024/overview.htm

High-level panel

The future of CBDCs: the road ahead for retail versus wholesale CBDCs
Technology is evolving rapidly, and many experiments in the area of CBDC are in progress or have been concluded. Policy makers are still observing and deciding any next steps. In that context, panellists will discuss the future of retail and wholesale CBDCs.
Speakers:  

1. Shaktikanta Das, Governor, Reserve Bank of India, Blockchain-based tokens can facilitate peer-to-peer payments, but future advancements are needed, such as: 1) programmable features; 2) interest-bearing or interest-free options; 3) offline usability; 4) digital representation of physical cash; 5) varying levels of access control. When comparing fast payment systems to tokenized central bank digital currency (CBDC) payments linked to universal basic income (UBI) bank accounts, tokenized CBDC payments offer advantages such as: 1) enhanced efficiency and transparency; 2) capability to accommodate various token types; 3) automation through programmable features.
2. Joachim Nagel, President, Deutsche Bundesbank There’s a need to accelerate the development of digital currency, and CBDCs will be distinct. A single distributed ledger technology (DLT) platform can support a wide range of services.
3. Fabio Panetta, Governor, Bank of Italy Difficulties encountered with centralized CBDCs include: 1) challenges in handling a large volume of system requests and transactions in retail payments; 2) difficulty in achieving privacy. Additionally, CBDCs must consider facilitating convenient and cost-effective cross-border transactions as a functional requirement. Tokenization options include: 1) each country creating its own token; 2) utilizing an EU DLT process for wholesale settlement. In the future, there may be a greater demand for data engineers rather than economic analysts.

Showcase:

1. project Mandala https://www.bis.org/about/bisih/topics/cbdc/mandala.htm
   
   

2. project mBridge https://www.bis.org/about/bisih/topics/cbdc/mcbdc_bridge.htm
   
   
   
   
   

screenshot of HK central bank system, trading from e-HKD to e-THB via mBridge.

Full video link ==> https://www.youtube.com/watch?v=V2UJ9xzbJGs

reference: https://docs.axelar.dev/

跨链转移Token

情况一：Call sendToken() on an EVM source chain
- step 1: 找到 source chain 的 Gateway 的合约地址。
EVM 链使用 Axelar Gateway 智能合约发送Token。 这些是应用程序层智能合约，用于发送和接收有效负载以及监控交易状态。
Gateway合约的接口如下。

1
2
3
4
5
6

function sendToken(
    string memory destinationChain,
    string memory destinationAddress,
    string memory symbol,
    uint256 amount
) external;

- step 2: 调用 source chain 的approve()。
- step 3: 在 source chain 上，利用Gateway合约将调用sendToken()。

1
2
3
4
5
6

sendToken(
    "avalanche", // destination chain name
    "0xF16DfB26e1FEc993E085092563ECFAEaDa7eD7fD", // some destination wallet address (should be your own)
    "axlUSDC", // asset symbol, can be differ by chain, see above
    100000000 // amount (in atomic units)
)

此时，token将出现在目标链（destination chain）的地址上。

情况二：## Call sendToken() on a Cosmos-based source chain
基于COSMOS的 source chain的话，sendToken()是一笔IBC的交易。消息（message）被投送到 Axelar 到一个固定的地址上axelar1dv4u5k73pzqrxlzujxg3qp8kvc3pje7jtdvu72npnt5zhq05ejcsn5qme5，该地址在Axelar网络上，被用于接收GMP消息，消息格式如下：

1
2
3
4
5
6

{
  destination_chain,
  destination_address,
  payload: null,
  type: 3, // corresponds to the `sendToken` command on Axelar
}

利用AxelarJS SDK调用sendToken()

前端应用可以利用AxelarJS SDK调用sendToken()。

使用存款地址（deposit address）转移资产

存款地址（deposit address）是由 Axelar 中继服务（Relayer）创建和监控的临时一次性地址。 存款地址通常最多可运行 24 小时。如果出现以下情况，请使用存款地址：

• 您需要 sendToken() 方法未提供的功能，例如 Cosmos-to-X。
• 您希望允许从不与 Axelar 交互的钱包进行Token转移，例如从中心化交易所提取资金时。
  如需使用存款地址转移资产，需要使用AxelarJS SDK并发起AxelarAssetTransfer。

构建跨链代币（Interchain Token）

链间代币是可在多个区块链上使用的 ERC-20 token。借助 Axelar 的链间代币服务 (Interchain Token Service)，可以从头开始创建新的跨链代币，也可以更新以太坊区块链上已存在的Token。如果Token不被 Axelar 支持，将该Token加入链间代币服务 (Interchain Token Service)即可。

Cos-CBDC: Design and Implementation of CBDC on Cosmos Blockchain:
https://www.ieice.org/publications/proceedings/bin/pdf_link.php?fname=p303-han.pdf&iconf=APNOMS&year=2021&vol=67&number=TS8-4&lang=E

• Cos-CBDC, a CBDC system based on Cosmos blockchain. The transaction capacity of Cos-CBDC can be up to 15,000 TPS depending on the block size and the number of validators in the BFT-based consensus algorithm.
• R3 Corda and Hyperledger Fabric as the blockchain platforms for CBDC, these platforms are not suitable for implementing cross border payments. COSMOS IBC allow different types of blockchains to trade tokens and data with each other.
• cos-CBDC propose multi signature (Multisig) and Multi-party computation (MPC). E.g. Central Bank, Commercial Bank, Customer, these 3 parties generate a Group Key with MPC. This Group Key.

The Bank of Korea’s CBDC research:
https://www.bis.org/publ/bppdf/bispap123_m.pdf

• there is no immediate need to issue CBDC in Korea. Therefore, the BOK is actively engaging in research and preparations so that if a decision is made in the future regarding the introduction of CBDC, it can be issued without any delay.
• Key considerations in the BOK’s CBDC research
  • The decline in the use of cash.
  • Big tech’s market dominance and concentration of personal information.
  • The proliferation of global stablecoins.