Let's Encrypt推出Sunlight专案，这是一个凭证透明度（Certificate Transparency，CT）日志实作，更符合现代Web公共金钥基础设施（PKI）的设计，官方提到，他们与知名资安专家Filippo Valsorda合作，并且参照广泛透明度日志记录社群的意见，开发出了Sunlight。

Web PKI是一种保护网际网路通讯的机制，仰赖数位凭证来验证实体身分并加密资料，而凭证透明度日志则是为了增加Web PKI系统透明度所加入的技术，由于任何人都可以检查和监控凭证的发行状况，因此有助于辨识错误或是恶意的凭证颁发，可以强化Web PKI的可信度。

Let's Encrypt从2019年以来，一直在运作公开的凭证透明度日志，虽然大致运作顺利，但还是有一些待解决的问题。最初Let's Encrypt的Oak日志架构采用关联式资料库，因此需要将每半年生成的资料，储存在独立的资料库分片（Shard）中。

但随著营运负担和成本增加，Let's Encrypt认为继续拆分出资料库并不是办法，因为目前凭证透明度日志分片大小约在5到10 TB左右，官方提到，这对於单一资料库来说非常大，之前他们就曾遭遇到MySQL存在16 TiB的限制，导致测试日志失败的案例。

扩大日志储存装置对Let's Encrypt来说是一个庞大的压力，官方表示，拥有高速磁碟和大量记忆体储存的执行个体并不便宜，凭证透明度日志可能因为客户端试图读取所有资料而导致过载，但是施加速率限制避免执行个体过载，又会使客户端运作缓慢，而这导致原本用于侦测错误凭证的透明度日志，成为快速颁发凭证的阻碍。

为此，Let's Encrypt建立了新的凭证透明度日志实作Sunlight专案。Sunlight采用一种称为Tiles的结构来储存和快取资料，以更有效地管理和提供凭证透明度日志中的资料。凭证透明度日志是一种二元树，每个节点都包含两个子节点的杂凑，而叶层级则包含日志的实际凭证资料，树的顶端经过数位签署，形成一个称为墨克树（Merkle Tree）的可加密验证结构。

这样的设计让任何人都可以验证日志中的凭证，同时也保证了日志的透明度和不可篡改性。虽然墨克树可用于校验资料的完整性，但是却需要进行大量的杂凑运算，对于非常大的资料集，可能产生效能瓶颈。

Sunlight的Tiles结构则是将大树切割成许多小块（下图），每块Tiles包含树的一部分，当需要查询特定凭证时，系统就只需找到包含该凭证的Tiles，而不需要从整棵树的根部开始搜寻。官方提到，Tiles API与之前CT API的动态端点不同，由于CT API需要根据凭证的杂凑值获取凭证证明，所以CT API对每个凭证都有不同回应，因此无法使用共享快取。

而Tiles API将树作为Tiles提供，便不需要动态运算或是请求处理，因此也就不需要API伺服器，而且因为Tiles是静态的，所以能够被有效地快取，另外，叶子Tiles还可以压缩储存，能够节省更多的储存空间。

将日志以一系列静态Tiles公开，使得Let's Encrypt可以用更便宜方式水平扩展日志服务，像是直接在S3等云端物件储存中切分Tiles，或是使用CDN、Web伺服器、档案系统等。由于物件和档案储存更易取得且可简单扩展，比云端资料库服务的成本更低。

另外，过去凭证透明度日志采用了一种称为合并延迟（Merge Delay）设计，来限制提交日志的延迟。意思是向日志提交凭证时，日志可以立刻回传签署凭证的时间戳记，并承诺在日志最大合并延迟，通常是24小时内，在日志中包含凭证。

也就是说，合并延迟是一个凭证被提交到日志之后，与实际被合并进日志的时间延迟，这种延迟让日志营运者有时间进行不要的处理和验证，但这也代表有一段时间，凭证存在却没有公开纪录。这样的情况可能导致一些问题，像是日志服务出现问题，导致无法在最大合并延迟内将凭证合并到日志中，如此日志就无法履行对提交凭证的承诺，而影响凭证的有效性，而且没有即时合并凭证，攻击者也可能趁著空窗时间进行恶意行为。

因此Sunlight采用批次处理的方法，将凭证以批次的方式整合到日志中，而这会导致提交凭证过程增加一些延迟，但官方表示，这轻微的延迟可以避免常见凭证透明度日志失败的情况。

Let's Encrypt目前已经发布了Sunlight软体与规范，并开始运行Sunlight凭证透明度日志服务，官方建议凭证颁发机构开始测试提交凭证资料到新的Sunlight日志中，也建议让凭证透明度程式考虑信任该新架构日志。