# BLS DUMP Just to preface, I'm viewing the `map-to-curve` as the following process: - First a field point `t` is passed into a SWU (simplified Shallue van de Woestijne Ulas) which I'm viewing as a "magic machine", taking `t` as an input and outputting a point `P'` on an auxiliary curve `E'`. - Then this point `P'` is fed into the isogeny "machine" to give us a point `P` on the BLS curve `E`. My definition of the isogeny kernel: - The set of "special" points that when input into the isogeny polynomials gives us "nothing" -> the identity point at infinity. - I'm viewing these as traps during the `map-to-curve` process. - An `n` degree isogeny contains `n` kernel points, those that map to infinity. ## G1 MAP G1 uses an 11 degree isogeny, so its kernel contains 11 points on the auxiliary curve `E'` that map to the point at infinity on the BLS curve `E`. This includes the point at infinity (doesn't concern us the SWU map can never output infinity from an int `t`) and 10 others. These 10 others come in 5 pairs `t and -t`, that share x coords. `-t` is the additive inverse of `t`. Not all of the kernel points can be reached by the SWU map. And like you say we have to solve the inverse SWU equation to find field points `t`. Essentially solving for `t` in the equation below: ``` x1 = (-B / A) * (1 + tv1) ``` Note this is found here: https://eips.ethereum.org/assets/eip-2537/field_to_curve, in the **Simplified SWU for AB != 0** section, operation 2. I'm not 100% sure on the maths to solve for `t` but in the sage script which I copied this is the important section: ```python discriminant = 1 - 4/(A / B * x + 1) zt2 = (−1 ± sqrt(discriminant))/2 t2 = zt2 / Z if t2.is_square(): t = t2.sqrt() ``` From that script I get 4 points: `t1, t2, t3, t4`, not 5. Not all of the iso kernel points are reachable by the SWU map. We need both the the discriminant and the resulting `t2` to be a square in `Fq` (set of all integers from 0 up to `q−1`, where `q` is the prime number that defines the size of `Fq`). So I think its the case that out of the 5 possible x-coords in the kernel only 4 are reachable via the SWU map. We can then get the additive inverse those 4 points: `-t1, -t2, -t3, -t4`, using the following behaviour: `(−t) mod p === (p − t) mod p`. In python we are doing this: ```python FP((Spec.P - t.x) % Spec.P), ``` This gives us 8 out of the possible 10. Where the last 2 (pair) are not reachable from the SWU map. These points all map to the G1 identity point at infinity, confirmed when filling the tests. ## G2 MAP G2 uses a 3 degree isogeny, so its kernel contains 3 points on the auxiliary curve `E'`. As with G1, this includes the point at infinity (doesn't concern us the SWU map can never output infinity from an int `t`) but 2 others. These 2 other come in a single pair: `t and -t`. And again its theoretically possible that not all of the iso kernel points are reachable by the SWU map. After writing out my understanding for G1, I have generated a `t` and its inverse `-t` using the same approach as G1 with the sage script. I think I am back tracking on what I mentioned earlier today about it mathematically not being possible for G2. I technically have generated a point that based on what I've explained for G1 should map to infinity. But with `py_ecc` it does not. I thought it was because of it might have triggered the exceptional case where when you have: ``` Z^2 * t^4 + Z * t^2 == 0 ``` You use the following x: ``` x1 = B / (Z * A) ``` Either I am wrong (most likely) or `py_ecc` could have a bug (unlikely). This the point I generated if you wanted to try test it out in ethjs against the other implemenations: ``` 1321391878976200074119645034444121025665939532471580297403784397444487204385014689930429494040875145883332046150361 + 2445707658947438392540268931313688646028792845302972805205282500613101640661654934098821383626938971038899010733909*u ``` More info on the generation with sage here: https://github.com/ethereum/execution-spec-tests/pull/1350/files#diff-22e485134295bbe49294f2de1df007216bd4b00f1abea033fe740e122d952e7dR589-R643