Both are curves of the Barreto-Lynn-Scott family with an embedding degree of 12.
They were constructed as a consequence of the improvements
to the Number Field Sieve for computing discrete logarithms in fields $\mathbb{F}_{p^n}$ with a prime $p$ and a small value $n$ that severely impacted the security level of BN curves that were previously widely used for instantiating pairing-based cryptography in practice. (See https://eprint.iacr.org/2016/1102.pdf).
The interesting thing about these BLS12 curves is that they are "pairing friendly". To be precise, they are meant to be used in the frame of pairing-cryptography where we have an efficient "Type-III" pairing (where an efficient isomorphism $\mathbb{G}_2\rightarrow \mathbb{G}_1$ is believed not to exist) that can be computed in practice. Our pairing is a bilinear map:
$$e: \mathbb{G}_1 \times \mathbb{G}_2 \rightarrow \mathbb{G}_t$$
Our pairing is defined over these groups $\mathbb{G}_{\{1,2,t\}}$ and good candidates for these groups are defined over elliptic curves, since elliptic curves allow for faster arithmetic and smaller bit sizes than groups defined over finite fields directly.
So, here comes the elliptic curves: BLS12-381 was first introduced in 2017, while BLS12-377 was introduced in 2018.
The first difference between both is their base field:
- BLS12-377 is defined over the field generated by the prime
q = 0x01ae3a4617c510eac63b05c06ca1493b1a22d9f300f5138f1ef3622fba094800170b5d44300000008508c00000000001 which is a 377 bit prime.
- BLS12-381 is defined over the field generated by the prime
q = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab which is a 381 bit prime.
This is roughly the size of the coordinates of the points on each curve.
Both are smaller than 384 bits, but larger than 320 bits, which from an implementation point of view mean they can be represented using only 6 words of 64 bits each. Nothing dramatically different there.
Notice that they are both believed to have a "security level" of ~120 bits, following the latest advances in breaking such curves. This is not great, but still acceptable and still considered infeasible to break with today's knowledge and tech. Here's a good blog post on the topic.
Next difference, as pointed out by @fgrieu, both have a different kind of "twist".
Both were constructed following construction 6.6 in the 2006 taxonomy of pairing-friendly curves paper, in the case where $k \equiv 0 \mod 6$, and as such have a "CM Discriminant" equal to 3 (here's a table with the different parameters).
This means they both have a twist of degree 6 (aka "sextic twist"), which is what the paper about constructing BLS12 curves recommended for fast arithmetic and probably why they were constructed using this method.
There are always 2 possible sextic twists for such BLS12 curves, but they have different orders depending on the parameters and curves at hand. The "right twist" for our usage is the one whose order is divisible by $r$, the size of the pairing-friendly subgroup (we'll see below why). The $r$ values of both are:
- for BLS12-381:
r= 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001
- for BLS12-377:
r= 0x12ab655e9a2ca55660b44d1e5c37b00159aa76fed00000010a11800000000001
And because of that, they have a different type of twist:
- BLS12-381 has a "type-M twist": $(E_t/\mathbb{F}_p^2): Y^2 = X^3+4(u+1)$
- BLS12-377 has a "type-D twist": $(E_t/\mathbb{F}_p^2): Y^2 = X^3+1/u$
Note that they both have a low-hamming weight $u$ value, which is good since it will be the number of addition steps in Miller Loop's algorithm to compute pairings:
- BLS12-381 has $u = -0xd201000000010000 = -2^{63}-2^{62}-2^{60}-2^{57}-2^{48}-2^{16}$, with a hamming weight of 6
- BLS12-377 has $u = 0x8508c00000000001 = 2^{63}+2^{58}+2^{56}+2^{51}+2^{47}+2^{46}+1$, with a hamming weight of 7
One the other side, given its slightly smaller field size, one could expect BLS12-377 to have slightly better performance compared to BLS12-381, which might well counter-act the lower hamming weight of its value $u$... The latter is also used more broadly and has seen better adoption so far and that means it has probably more refined implementations.
So now that we've seen all these parameters, the elliptic curves at hand, $E(F_q)$, have only one big subgroup of order $r$ and while it is a good candidate for our group $\mathbb{G}_1$, we need two different yet "compatible" groups to define our pairing. But a cool thing is that we can "extend" the field over which we're defining our elliptic curve, and by doing so we can end up with an elliptic curve $E'$ defined over its extension $F_{q^k}$ of degree $k$ that will contain more than 1 subgroup of said order $r$ for sure. In the BLS12 family case, our extension is of degree 12 (the famous embedding degree mentioned in my very first sentence), and that is giving us a good candidate for our group $\mathbb{G}_2$.
Now, the twist is becoming important here, because when we're working in a field extension of degree 12, doing arithmetic is really slow!
So a "trick" to speed up computation is to rely on a way to map our curve $E({F}_{q^{12}})$ onto a nicer curve defined over a lower degree field and this is where the twist of order divisible by $r$ comes in! (By Lagrange's theorem, to have a subgroup of size $r$ its order must be divisible by $r$.)
And we can use a map from the curve to its twist to operate in the twist instead of in the extension field.
So, the fact that they both have a twist of degree 6 means that we can reduce our extension field by a factor of six when using the twist, which is the biggest divisor of 12 that isn't 12 itself. So having $\mathbb{G}_2$ be on the twist means we're doing computation in $F_{q^2}$ instead of ${F}_{q^{12}}$, and it's much easier to do computation there.
This difference in term of twist means that we don't have the same map to map from the twisted curve onto the original curve. But my belief is that the recent formulas we have to compute pairings can operate entirely in the twist, and so the difference of twist type might not matter at all at the implementation level depending on which formulas are implemented for the curves' arithmetic.
Finally to really answer your question with a more concrete example, while the two are not exactly the same, they still have a lot in common at the implementation level, e.g. the Go Kilic BLS12-377 library is actually adapted from the Go Kilic BLS12-381 one, with relatively few changes, the main differences being mostly the curve parameters and the field parameters, which have consequences on the way we do arithmetic (especially in the assembly code), but the bulk of the code itself remains the same for both.
PS: a good read about BLS12-381 and pairing-friendly curves is "BLS12-381 for the rest of us", it also covers a lot of the above in more details.
