<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Bls on As it was</title>
    <link>https://galoishlee.github.io/tags/bls/</link>
    <description>Recent content in Bls on As it was</description>
    <generator>Hugo</generator>
    <language>zh-CN</language>
    <managingEditor>maocred@gmail.com (Halois)</managingEditor>
    <webMaster>maocred@gmail.com (Halois)</webMaster>
    <copyright>This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.</copyright>
    <lastBuildDate>Mon, 16 Mar 2026 00:00:00 +0800</lastBuildDate>
    <atom:link href="https://galoishlee.github.io/tags/bls/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Hash To Curve</title>
      <link>https://galoishlee.github.io/hash-to-curve/</link>
      <pubDate>Mon, 16 Mar 2026 00:00:00 +0800</pubDate><author>maocred@gmail.com (Halois)</author>
      <guid>https://galoishlee.github.io/hash-to-curve/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;Reading: RFC 9380, &lt;em&gt;Hashing to Elliptic Curves&lt;/em&gt;.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;Core problem: given an arbitrary byte string, produce a point in the correct elliptic-curve subgroup, with the distribution and side-channel properties a protocol actually needs. This is not “hash to an $x$ and try to solve for $y$”.&lt;/p&gt;&#xA;&lt;p&gt;The RFC answer is a pipeline, not a trick:&lt;/p&gt;&#xA;$$&#xA;\text{bytes} \rightarrow \text{field elements} \rightarrow \text{curve points} \rightarrow \text{subgroup points}&#xA;$$&lt;p&gt;plus domain separation and constant-time constraints.&lt;sup id=&#34;fnref:1&#34;&gt;&lt;a href=&#34;#fn:1&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;1&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;&#xA;&lt;p&gt;This note only tracks that structure: what object the RFC is defining, why &lt;code&gt;encode_to_curve&lt;/code&gt; and &lt;code&gt;hash_to_curve&lt;/code&gt; differ, and why suites such as secp256k1 and BLS12-381 are built the way they are.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Pairing-Friendly Curves 的数学结构与协议动机</title>
      <link>https://galoishlee.github.io/pairing-friendly-curves-motivation/</link>
      <pubDate>Sun, 14 Dec 2025 08:00:00 +0800</pubDate><author>maocred@gmail.com (Halois)</author>
      <guid>https://galoishlee.github.io/pairing-friendly-curves-motivation/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;Reading: pairing is a verifier interface, not a prestige upgrade.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;前 3 篇已经把 ECC 子系列的前半段压实了：Web3 为什么不会只用一条曲线，账户层为什么长期停在 secp256k1，以及 signer-side 风险如何从 ECDLP 走向 nonce leakage。到这里，新的问题自然出现：既然账户层不需要 pairing，为什么 BLS signatures、SNARK verifier 和 KZG 却总会把 pairing-friendly curves 拉进来？&lt;/p&gt;&#xA;&lt;p&gt;关键不在“这类曲线更先进”，而在“这类协议的 verifier 从一开始就需要另一种代数接口”。普通离散对数群擅长表达签名关系；pairing-friendly setting 则擅长把分散在多个群元素、多个约束甚至多个消息上的关系压缩成少数几个 pairing checks。也就是说，这里发生的不是曲线选型审美，而是 protocol verification compression。&lt;sup id=&#34;fnref:1&#34;&gt;&lt;a href=&#34;#fn:1&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;1&lt;/a&gt;&lt;/sup&gt; &lt;sup id=&#34;fnref:2&#34;&gt;&lt;a href=&#34;#fn:2&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;2&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;&#xA;&lt;p&gt;所以这一篇不会把 pairing 写成完整教材。更有用的顺序是：先定义最小 bilinear map properties，再给出一个 minimal pairing equation pattern，随后分别说明 BLS signatures、SNARK verifier intuition 和 KZG opening verification 为什么会消费同一类接口。最后再把这些数学对象压成工程实现对接边界。&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;Quick Note.&#xA;This article defines the minimal bilinear map properties needed for protocol use. It also explains why pairings enable aggregate signature verification and polynomial opening verification, gives the minimal pairing equation pattern, and shows the mapping from bilinearity to protocol verification compression. It deliberately avoids expanding into full Miller-loop or final-exponentiation implementation details.&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
  </channel>
</rss>
