lookup_any的一个取0问题

[mdj33]

https://github.com/privacy-scaling-explorations/halo2/blob/9b33f9ce524dbb9133fc8b9638b2afd0571659a8/halo2_proofs/src/dev.rs#L1800

在测试这个bad_lookup_any用例时候遇到一个疑问
比如电路
{
a: advice_column,
table: instance
}
在用例中instance设置为 1,2,4,6， 如果把a设置为9，lookup失败，没问题，但是如果a设置为0，lookup是能通过的，这感觉不对

从代码实现来看，是把所有值跟fill_row值比较，不同的才抽取出来，但是fill_row为0， 所以，a为0时候就没提取，就能通过，这是bug吗

[qizhou]

的确是一个有意思的问题，我觉得可以直接去PSE问问这种情况到底是允许还是bug？

[mdj33]

lookup_any不算blinding部分，会pad 0, 比如input是2， table是1,2,3,4, input会pad成 2,0,0.., table会pad成 1,2,3,4,0.., 跟lookup table column不太一样，个人觉得table pad成第一个value会更合理，这样就能排除input是0， table不包含0的问题。 但是，同时input的pad也应该是比如第一个值，否则相当于人为加了一个0的input

[mdj33]

最后的结论：
实际测试的结果是：
对table_column, 系统保证了在TableLayouter. assign_cell时候会pad table的第一个值
lookup的input column是会根据实际计算值来，如果计算是0，就是0
举例来说（k=4)：

1. lookup_any, input: 2,4, table: 2,4,6, 最后的input列为2,4,0,0..., table为 2,4,6,0,0... 可以通过
2. lookup, input:2,4, table as table_column: 2,4,6, 最后的input列为2,4,0,0..., table为 2,4,6,2,2... 不能通过

所以，对input列，要注意设置非enable的值，比如pse版本的halo2的bad_fixed_lookup() UT：
// If q is enabled, a must be in the table.
// When q is not enabled, lookup the default value instead.
let not_q = Expression::Constant(Fp::one()) - q.clone();
let default = Expression::Constant(Fp::from(2));
vec![(q * a + not_q * default, table)]

所以正确与否，要看怎么定义这个列了，比如定义input的 lookup的是某几个cell，而table也是某几个cell，
比如Input: 0, table:2,4, 但是从整列的角度来看0确实是对的，因为table的其他cell就是0， 但是就map(input cell, table cell) 来看，这里还是有些奇怪的， 因为0 包含在2,4里面的时候，lookup是对的

[dajuguan]

• 问题复现: 采用lookup_any进行查找约束，输入witness列包含0, 如[2,0,4]; 查找table未填满，比如为[2,4,6,8]。
• 期望结果: 因为table中不包含0, 期望lookup失败。
• 实际结果: lookup约束成功
• 原因: 默认在lookup_any时会把该table未填满的部分补零(区别于lookup则是pad table的第一row的值)。假设k=3, 则table变为[2,4,6,8,0,0,0,0]
• 复现代码: https://github.com/dajuguan/halo2_research/blob/main/src/lookup_padding.rs

[Demian101]

lookup padding 的是 0
lookup_any padding 的是 t[0]
!q_selector --- 取反