Different researchers use different notations for elliptic curve bilinear pairing groups. For symmetric pairing this can look like:
- $e: \; \mathbb{G} \times \mathbb{G} \rightarrow \mathbb{G}_T$
- $e: \; \mathbb{G}_1 \times \mathbb{G}_1 \rightarrow \mathbb{G}_T$
- $e: \; \mathbb{G}_1 \times \mathbb{G}_1 \rightarrow \mathbb{G}_2$
- $e: \; \mathbb{G}_1 \times \mathbb{G}_2 \rightarrow \mathbb{G}_T$ (with $\mathbb{G}_1 = \mathbb{G}_2$ for symmetric and $\mathbb{G}_1 \neq \mathbb{G}_2$ for asymmetric)
All of the symmetric variants mean the exact same thing and only differ notationally.
Now, if a scheme is constructed from asymmetric pairing, there is nothing holding you back from instantiating the scheme with a symmetric pairing, other than possible security concerns and enabling attacks on it. So, theoretically we can calculate the size of the user secret key as $|SK| = 2|\mathbb{G}| = |\mathbb{G}|+|\mathbb{G}|$ instead of $|SK| = |\mathbb{G}_1|+|\mathbb{G}_2|$. Now you only need to use one group instead of two, which is a more compact notation, but not entirely true.
The authors of both papers that you referenced probably chose this notation in order to include everything in a single table, because the page width is limited and they can't severely change the font size, because they need to follow the template of the conference/journal.
Now, your question is why the authors of the ODG scheme calculated the size of the secret keys of the GSWV scheme differently than the authors of the GSWV scheme themselves.
Let's recap elliptic curve groups. We have an elliptic curve, such as $y^2 = x^3+a\cdot x+b$ where $a$ and $b$ are curve parameters, that is defined in two-dimensional space over some (prime) field. Each point on the curve, where the above equation holds, is represented by two elements, $x$ and $y$, from the underlying field.
If the field is a 160-bit prime-order field, then elements of $\mathbb{G}_1$ can be serialized to 320-bit as a concatenation of $x$ and $y$. But we don't necessarily have to store $y$, because if we know the curve, then we can simply calculate $y$ from $x$:
$$y = \sqrt{(x^2+a)\cdot x + b}$$
Example in code from jPBC:
protected void setPointFromX() {
infFlag = 0;
y.set(x.duplicate().square().add(field.a).mul(x).add(field.b).sqrt());
}
So, you can reduce the size of the serialized curve element by half, but then you would need to do additional calculations in order to reconstruct the curve element from $x$ in order to use it. It's a compromise. The authors of GPSW chose to optimize for size and the authors of ODG chose to optimize for speed (or simply to let their scheme look good).
