2. 批次数据结构
和交易一样，批次也是采用Protocol Buffesr来做序列化。它也包括数值字节和字符串，两种信息类型。
在批次（Batch）里存放三部分信息，分别是标头内容（header）、标头签名（header_signature）、交易集合（transactions）。其中标头内容是序列化的批次头文件。
在批次头文件（BatchHeader）里存放两项信息，签发者公钥（signer_public_key），交易ID（transaction_ids）
2.1 批次头、签名和公钥
延续交易数据结构的模式， 批次的标头内容是一个序列化的批次头。标头内容被交易发起者使用私钥进行签名（私钥并不存放在批次里），完成的签名被存放在header_signature. 标头内容以序列化的字节形式呈现，这样就可以通过批次回执上的签名来验证它。
序列化的结果文件被交易者用私钥（采用椭圆曲线加密方式）进行签名。
验证组件接受标准化的64字节压缩签名，这是签名的R部分和S部分的结合体。一些资料库会包含一个额外的头字节，可恢复的身份域，或提供DER加密签名。锯齿湖拒绝任何非64字节的签名。
注意：椭圆曲线签名必须采用“low S”形式（即“low S”签名）。也就是说这里的椭圆曲线签名必须计算（R,S）和（R,N-S），此处的N是secp256k1曲线的阶。有效的签名是在(S,N-S)中取最小值。否则，锯齿湖将拒绝交易签名。Python3的锯齿湖SDK和来自于比特币的椭圆曲线加密资料库的不存在以上问题。如果使用如mbed TLS和openSSL的资料库，就不是采用以上标准化签名方法。
2.2 交易集合
批次里的交易集合（transactions）是组成这个批次的所有交易(Transaction)的列表。交易结合按照列表排序。在批次头文件（BatchHeader）里的交易ID（transaction_ids）是该批次内每个交易(Transaction)里的标头内容签名(header_signature)组成的列表，该列表的次序应该和交易集合（transactions）一致。
