File size: 96,232 Bytes
a0f50f5 |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 |
---
tags:
- sentence-transformers
- sentence-similarity
- feature-extraction
- generated_from_trainer
- dataset_size:278
- loss:MatryoshkaLoss
- loss:MultipleNegativesRankingLoss
base_model: BAAI/bge-base-en-v1.5
widget:
- source_sentence: How does Bitcoin's P2P network prevent malicious nodes from flooding
the network with invalid blocks or transactions?
sentences:
- 'paper-title: The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
\subsection*{8.4 Payment Routing}
It is theoretically possible to build a route map implicitly from observing 2
-of-2 multisigs on the blockchain to build a routing table. Note, however, this
is not feasible with pay-to-script-hash transaction outputs, which can be resolved
out-of-band from the bitcoin protocol via a third party routing service. Building
a routing table will become necessary for large operators (e.g. BGP, Cjdns). Eventually,
with optimizations, the network will look a lot like the correspondent banking
network, or Tier-1 ISPs. Similar to how packets still reach their destination
on your home network connection, not all participants need to have a full routing
table. The core Tier-1 routes can be online all the time - while nodes at the
edges, such as average users, would be connected intermittently.
Node discovery can occur along the edges by pre-selecting and offering partial
routes to well-known nodes.
\subsection*{8.5 Fees}
Lightning Network fees, which differ from blockchain fees, are paid directly between
participants within the channel. The fees pay for the time-value of money for
consuming the channel for a determined maximum period of time, and for counterparty
risk of non-communication.
Counterparty risk for fees only exist with one''s direct channel counterparty.
If a node two hops away decides to disconnect and their transaction gets broadcast
on the blockchain, one''s direct counterparties should not broadcast on the blockchain,
but continue to update via novation with a new Commitment Transaction. See the
Decrementing Timelocks entry in the HTLC section for more information about counterparty
risk.
The time-value of fees pays for consuming time (e.g. 3 days) and is conceptually
equivalent to a gold lease rate without custodial risk; it is the time-value for
using up the access to money for a very short duration. Since certain paths may
become very profitable in one direction, it is possible for fees to be negative
to encourage the channel to be available for those profitable paths.
\section*{9 Risks}
The primary risks relate to timelock expiration. Additionally, for core nodes
and possibly some merchants to be able to route funds, the keys must be held online
for lower latency. However, end-users and nodes are able to keep their private
keys firewalled off in cold storage.
\subsection*{9.1 Improper Timelocks}
Participants must choose timelocks with sufficient amounts of time. If insufficient
time is given, it is possible that timelocked transactions believed to be invalid
will become valid, enabling coin theft by the counterparty. There is a trade-off
between longer timelocks and the time-value of money. When writing wallet and
Lightning Network application software, it is necessary to ensure that sufficient
time is given and users are able to have their transactions enter into the blockchain
when interacting with non-cooperative or malicious channel counterparties.
\subsection*{9.2 Forced Expiration Spam}
Forced expiration of many transactions may be the greatest systemic risk when
using the Lightning Network. If a malicious participant creates many channels
and forces them all to expire at once, these may overwhelm block data capacity,
forcing expiration and broadcast to the blockchain. The result would be mass spam
on the bitcoin network. The spam may delay transactions to the point where other
locktimed transactions become valid.
This may be mitigated by permitting one transaction replacement on all pending
transactions. Anti-spam can be used by permitting only one transaction replacement
of a higher sequence number by the inverse of an even or odd number. For example,
if an odd sequence number was broadcast, permit a replacement to a higher even
number only once. Transactions would use the sequence number in an orderly way
to replace other transactions. This mitigates the risk assuming honest miners.
This attack is extremely high risk, as incorrect broadcast of Commitment Transactions
entail a full penalty of all funds in the channel.
Additionally, one may attempt to steal HTLC transactions by forcing a timeout
transaction to go through when it should not. This can be easily mitigated by
having each transfer inside the channel be lower than the total transaction fees
used. Since transactions are extremely cheap and do not hit the blockchain with
cooperative channel counterparties, large transfers of value can be split into
many small transfers. This attempt can only work if the blocks are completely
full for a long time. While it is possible to mitigate it using a longer HTLC
timeout duration, variable block sizes may become common, which may need mitigations.
If this type of transaction becomes the dominant form of transactions which are
included on the blockchain, it may become necessary to increase the block size
and run a variable blocksize structure and timestop flags as described in the
section below. This can create sufficient penalties and disincentives to be highly
unprofitable and unsuccessful for attackers, as attackers lose all their funds
from broadcasting the wrong transaction, to the point where it will never occur.'
- 'paper-title: OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding
Fig. 11: Bootstrap bandwidth consumption with state blocks.\\[0pt]
to create the UTXO state. For this experiment, we reconstructed Bitcoin''s blockchain
[5], [41] and created a parallel OmniLedger blockchain with weekly state blocks.
Figure 11 depicts the bandwidth overhead of a validator that did not follow the
state for the first 100 days. As we can see, the state block approach is better
if the validator is outdated for more than 19 days or 2736 Bitcoin blocks.
The benefit might not seem substantial for Bitcoin, but in OmniLedger, 2736 blocks
are created in less than 8 hours, meaning that for one day-long epochs, the state
block approach is significantly better. If a peak throughput is required and 16
MB blocks are deployed, we expect reduced bandwidth consumption close to two orders
of magnitude.
\section*{IX. Related Work}
The growing interests in scaling blockchains have produced a number of prominent
systems that we compare in Table IV. ByzCoin [32] is a first step to scalable
BFT consensus, but cannot scale-out. Elastico is the first open scale-out DL,
however, it suffers from performance and security challenges that we have already
discussed in Section II. RSCoin [16] proposes sharding as a scalable approach
for centrally banked cryptocurrencies. RSCoin relies on a trusted source of randomness
for sharding and auditing, making its usage problematic in trustless settings.
Furthermore, to validate transactions, each shard has to coordinate with the client
and instead of running BFT, RSCoin uses a simple two-phase commit, assuming that
safety is preserved if the majority of validators is honest. This
TABLE IV: Comparison of Distributed Ledger Systems
\begin{center}
\begin{tabular}{ccccccc}
\hline
System & Scale-Out & \begin{tabular}{c}
Cross-Shard \\
Transaction Atomicity \\
\end{tabular} & State Blocks & \begin{tabular}{c}
Measured Scalability \\
(\# of Validators) \\
\end{tabular} & \begin{tabular}{c}
Estimated \\
Time to Fail \\
\end{tabular} & \begin{tabular}{c}
Measured \\
Latency \\
\end{tabular} \\
\hline
RSCoin [16] & In Permissioned & Partial & No & 30 & N/A & 1 sec \\
Elastico [34] & In PoW & No & No & 1600 & 1 hour & 800 sec \\
ByzCoin [32] & No & N/A & No & 1008 & 19 years & 40 sec \\
Bitcoin-NG [21] & No & N/A & No & 1000 & N/A & 600 sec \\
PBFT [9], [11] & No & N/A & No & 16 & N/A & 1 sec \\
Nakamoto [36] & No & N/A & No & 4000 & N/A & 600 sec \\
OmniLedger & Yes & Yes & Yes & 2400 & 68.5 years & 1.5 sec \\
\hline
\end{tabular}
\end{center}
approach, however, does not protect from double spending attempts by a malicious
client colluding with a validator.
In short, prior solutions [16], [32], [34] achieve only two out of the three desired
properties; decentralization, long-term security, and scale-out, as illustrated
in Figure 1. OmniLedger overcomes this issue by scaling out, as far as throughput
is concerned, and by maintaining consistency to the level required for safety,
without imposing a total order.
Bitcoin-NG scales Bitcoin without changing the consensus algorithm by observing
that the PoW process does not have to be the same as the transaction validation
process; this results in two separate timelines: one slow for PoW and one fast
for transaction validation. Although Bitcoin-NG significantly increases the throughput
of Bitcoin, it is still susceptible to the same attacks as Bitcoin [24], [3].
Other efforts to scale blockchains include: Tendermint [9], a protocol similar
to PBFT for shard-level consensus that does not scale due to its similarities
to PBFT, and the Lightning Network [40], an off-chain payment protocol for Bitcoin
(also compatible to OmniLedger); it limits the amount of information committed
to the blockchain.'
- "Datatype: lecture_note, Title: Lecture 4: Peer to Peer Networking for Blockchains\n\
\nHow does broadcast take only $O(\\log N)$ steps? We first need to understand\
\ the gossip-flooding-based broadcast protocol. The flooding protocol mimics the\
\ spread of an epidemic. Once a node is ``infected\", it infects its peers and\
\ forever stay's infected. It is easy to see that the spread of information will\
\ happen exponentially; hence the information will take $O(\\log N)$ hops to spread\
\ to all nodes. To formally understand the spread, we note that $d$-regular graphs\
\ with $d\\geq 3$ are an \\textit{expander graph} for large sizes ($|V|$) with\
\ high probability. An expander graph is a connected but sparse graph ($|E|=O(|V|)$)\
\ with the following property: $|\\partial A| \\geq \\epsilon|A|$ for any connected\
\ sub-graph $A$ with $|A|<0.5|V|$. Here, $|\\partial A|$ refers to the number\
\ of vertices outside $A$ with at least one neighbor in $A$. A gossip message\
\ originates with $A(0)$ as the broadcasting node with $|A(0)|=1$, in the next\
\ hop, it will spread to $\\partial A(0)$ with $|A(1)|\\geq (1+\\epsilon)|A(0)|$.\
\ This recursion continues and we have $|A(k)|\\geq(1+\\epsilon)^kA(0)$. Thus,\
\ the number of steps to reach half the number of nodes is logarithmic in the\
\ number of nodes. It can be shown that the other half of the nodes can also be\
\ covered in $O(\\log N)$ time.\n\n\n%Engineering issues (peer discovery, bootstrap,\
\ churn). Implementation connections (to the lab experiment). Validation of tx,\
\ blocks. How does that impact networking? What about skipping validation and\
\ doing cut-through routing? Compact blocks. (RR)\n\n\\section*{Bitcoin P2P network:\
\ A systems view}\nIn Bitcoin, peers connect to each other and communicate using\
\ the TCP protocol. The codebase allows for eight outgoing connections and up\
\ to 117 incoming connections. The network has a high churn rate (rate at which\
\ users enter/leave the system); hence, the node must be ready to connect to new\
\ peers. Moreover, to ensure that the peers we are connecting to are chosen randomly,\
\ the node keeps a large list of nodes running Bitcoin in the form of their (IP,\
\ port) tuple and establishes a connection to one of them randomly when a slot\
\ opens up. \n\nHow does a node bootstrap its list of peers? This happens by\
\ connecting to a set of DNS seed nodes. The seed nodes are not heavily decentralized;\
\ hence completely relying on the peer list provided by them is not advisable.\
\ On connecting to the initial set of peers, a node asks its neighbors for their\
\ peer list using {\\tt getAddr} and {\\tt Addr} messages. The node keeps refreshing\
\ its peer list regularly by exchanging peer lists with its peers. \n\nTransmission\
\ of all block and transactions happen through the inventory message {\\tt inv},\
\ on receiving an {\\tt inv} message the node checks if it has the block or the\
\ transaction in its local storage. If not, it sends the {\\tt getData} message\
\ to fetch those blocks and transactions from the peer. Since block sizes are\
\ relatively large, block transmission can optionally happen in 2 stages. On receiving\
\ the {\\tt inv} message, the node may ask for headers first using {\\tt getHeaders}\
\ and ask for complete blocks only if a header chain is established. This header-first\
\ block transmission increases queries but can decrease the net bandwidth usage.\
\ It may also prevent nodes from accepting PoW invalid blocks since the node can\
\ check from the header whether PoW is valid. \n\nWe saw in the previous lecture\
\ that some nodes might be malicious. A question that may arise is: what stops\
\ malicious nodes from flooding the network with invalid blocks and transactions\
\ (i.e., with invalid PoW and/or signatures)? Such flooding will saturate the\
\ network and increase transmission delay to unacceptable levels. Such an attack\
\ is prevented by a simple design decision, forward message to peers only after\
\ validating the message; i.e., a node sends an {\\tt inv} block message to its\
\ peers only after validating the block. If the adversary creates an invalid block,\
\ the block will not be propagated beyond one honest node. Additionally, nodes\
\ maintain their peers' reputation using some predefined heuristics; if a peer\
\ misbehaves (say by sending a transaction with invalid signatures), its reputation\
\ is downgraded and after a certain lower threshold is disconnected."
- source_sentence: How does the blockchain protocol ensure that all honest players
converge on the same chain?
sentences:
- "paper-title: Blockchain CAP Theorem Allows User-Dependent Adaptivity and Finality\n\
\nDefinition 3 (Potential starting value for period $p$ ). A value $v$ that has\
\ been next-voted by $t+1$ honest nodes for period $p-1$.\n\nDefinition 4 (Committed\
\ value for period $p$ ). A value $v$ that has been cert-voted by $2 t+1$ nodes\
\ for period $p$.\n\nDefinition 5 (Potentially committed value for period $p$\
\ ). A value $v$ that has been cert-voted by $t+1$ honest nodes for period $p$.\n\
\nAlthough we slightly altered Algorand BA protocol (which is highlighted in red\
\ in Appendix A), we note that our modification does not break the safety of the\
\ protocol or cause any deadlock in Lemma 1 and Lemma 2, At a high level, the\
\ validity check only causes less soft-votes from honest nodes, which is indistinguishable\
\ with the case where the leader is malicious and no value receives at least $2\
\ t+1$ soft-votes in some period. Therefore, the safety and deadlock-free property\
\ remain.\n\nLemma 1 (Asynchronous Safety, CP0). Even when the network is partitioned,\
\ the protocol ensures safety of the system so that no two honest nodes will finish\
\ one iteration of the protocol with different outputs.\n\nProof. The following\
\ properties hold even during a network partition.\n\n\\begin{itemize}\n \\item\
\ By quorum intersection, as each honest node only soft-votes one value, then\
\ at most one value is committed or potentially committed for each period $p$\
\ in one iteration.\n \\item If a value $v$ is potentially committed for period\
\ $p$, then only $v$ can receive $2 t+1$ next-votes for period $p$. Thus, the\
\ unique potential starting value for period $p+1$ is $v$.\n \\item If a period\
\ $p$ has a unique potential starting value $v \\neq \\perp$, then only $v$ can\
\ be committed for period $p$. Moreover, honest nodes will only next-vote $v$\
\ for period $p$, so the unique potential starting value for period $p+1$ is also\
\ $v$. Inductively, any future periods $p^{\\prime}>p$ can only have $v$ as a\
\ potential starting value. Thus, once a value is potentially committed, it becomes\
\ the unique value that can be committed or potentially committed for any future\
\ period, and no two honest nodes will finish this iteration of the protocol with\
\ different outputs.\n\\end{itemize}\n\nLemma 2 (Asynchronous Deadlock-freedom).\
\ As long as messages will be delivered eventually, an honest node can always\
\ leave period p, either by entering a higher period or meeting the halting condition\
\ for the current iteration.\n\nProof. We first prove that there can never exist\
\ $2 t+1$ next-votes for two different non- $\\perp$ values from the same period\
\ $p$ by induction.\n\nStart with $p=1$. Note that every honest node sets $s t_{i}^{1}=\\\
perp$ and at most one value (say $v$ ) could receive more than $2 t+1$ soft-votes.\
\ Therefore only value $v$ and $\\perp$ could potentially receive more than $2\
\ t+1$ next-votes in period 1 . Note that it is possible that both $v$ and $\\\
perp$ receive more than $2 t+1$ next-votes: all the honest nodes could next-vote\
\ for $\\perp$ in Step 4 and then next-vote for $v$ in Step 5 after seeing the\
\ $2 t+1$ soft-votes for $v$.\n\nAssume that the claim holds for period $p-1(p\
\ \\geq 2)$ : there exist at most two values each of which has $2 t+1$ next-votes\
\ for period $p-1$, and one of them is necessarily $\\perp$. Then there are three\
\ possible cases:"
- 'paper-title: A Scalable Proof-of-Stake Blockchain in the Open Setting * \\ (or,
How to Mimic Nakamoto''s Design via Proof-of-Stake)
Common prefix. Our analysis is based on the common prefix analysis of core-chain.
The core-chain can achieve common prefix as we discussed. The opportunity for
malicious players to destroy common prefix probability is to generate different
blockchain for the same core-chain. For the malicious players can sign different
blocks for one block-core, this will allow him to fork the blockchain. So the
malicious players can fork the blockchain when they are chosen to generate block.
However, with the property of hash function, the malicious players can not generate
two blocks with same hash value. When an honest player is chosen to extend a block,
he will only support one blockchain. Then all of the honest players will converge
on one blockchain.\\
Corollary 6.4 (Common prefix). Consider the blockchain protocol $\Pi^{\text {main
}}$. Consider $\alpha^{\star}=\lambda \beta^{\star}$, $\lambda>1$, and $\delta>0$.
Consider two honest PoS-players, P in round $r$ and $\mathrm{P}^{\prime}$ in round
$r^{\prime}$, with the local best PoS blockchains $\tilde{\mathcal{C}}, \tilde{\mathcal{C}}^{\prime}$,
respectively, where $r^{\prime} \geq r$. Then we have $\operatorname{Pr}\left[\tilde{\mathcal{C}}[1,
\ell] \preceq \tilde{\mathcal{C}}^{\prime}\right] \geq 1-e^{-\Omega(\kappa)}$,
where $\ell=\operatorname{len}(\mathcal{C})-\Theta(\kappa)$.
Proof. As we discussed, $\tilde{\mathcal{C}}$ and $\tilde{\mathcal{C}}^{\prime}$
are associated with core-chains $\mathcal{C}$ and $\mathcal{C}^{\prime}$ respectively.
From Corollary 5.6 we know that $\operatorname{Pr}\left[\mathcal{C}[1, \ell] \preceq
\mathcal{C}^{\prime}\right] \geq 1-e^{-\Omega(\kappa)}$.
Based on the assumption that $\alpha^{\star}=\lambda \beta^{\star}$ and $\lambda>1$,
we can have that the malicious players are not able to generate more than $\Theta(\kappa)$
blocks before an honest player is chosen to generate block with high probability.
All of the honest players will converge on the same chain. Put them together,
we have $\operatorname{Pr}\left[\tilde{\mathcal{C}}[1, \ell] \preceq \tilde{\mathcal{C}}^{\prime}\right]
\geq 1-e^{-\Omega(\kappa)}$ where $\ell=\operatorname{len}(\mathcal{C})-\Theta(\kappa)$.
Chain soundness. A new player will accept a blockchain (in which the corresponding
corechain is included). The proof idea for achieving chain soundness property
of our blockchain protocol directly follows that for the core-chain protocol.
We have the following statement.\\
Corollary 6.5 (Chain soundness). Consider the blockchain protocol $\Pi^{\text
{main }}$. Consider for every round, $\alpha=\lambda \beta, \lambda>1$, and $\delta>0$.
There are two honest PoS-players, $\mathrm{P}^{\prime}$ and $\mathrm{P}^{\prime
\prime}$ in round $r$, with the local best PoS blockchains $\tilde{\mathcal{C}}^{\prime}$
and $\tilde{\mathcal{C}}^{\prime \prime}$, respectively. Let $\mathrm{P}^{\prime}$
be a new player and $\mathrm{P}^{\prime \prime}$ be an existing player in round
$r$. Then we have $\tilde{\mathcal{C}}^{\prime}[\neg \kappa] \preceq \tilde{\mathcal{C}}^{\prime
\prime}$ and $\tilde{\mathcal{C}}^{\prime \prime}[\neg \kappa] \preceq \tilde{\mathcal{C}}^{\prime}$.'
- "Datatype: lecture_note, Title: Lecture 9: Scaling Latency\n\n\\begin{figure}\n\
\\begin{center}\n\\includegraphics[width=\\textwidth]{figures/Prism_main.pdf}\n\
\\end{center}\n\n\\caption{Factorizing the blocks into three types of blocks:\
\ proposer blocks, transaction blocks and voter blocks.}\n\\label{fig:prism}\n\
\n\\end{figure}\n\nJust as in {\\sf Prism 1.0}, the \\textit{proposer} blocktree\
\ in {\\sf Prism} anchors the blockchain. Each proposer block contains a list\
\ of reference links to \\textit{transaction} blocks that contain transactions,\
\ as well as a single reference to a parent proposer block. Honest nodes mine\
\ proposer blocks following the longest chain rule in the proposer tree.\nWe define\
\ the *level* of a proposer block as its distance from the genesis proposer block,\
\ and the *height* of the proposer tree as the maximum level that contains any\
\ proposer blocks. To determine the ordering of proposer blocks (and thus transaction\
\ blocks and transactions), we elect one \\textit{leader} proposer block from\
\ each level. The sequence of leader blocks up to the height of the proposer tree\
\ is called the \\textit{leader sequence}, and is determined by the *voter* chains.\
\ Note that the leader blocks do not need to follow the chain structure of the\
\ proposer blocks because otherwise deadlock may occur if conflicting blocks (i.e.,\
\ two proposer blocks not on one chain) are determined as leader blocks. \n\n\
In {\\sf Prism}, there are $m$ voter chains, where $m \\gg 1$ is a fixed parameter\
\ chosen by the system designer. The larger the $m$, the more parallel the voting\
\ process and hence the shorter the latency of confirmation. In general $m$ is\
\ chosen as large as network bandwidth and memory management issues are manageable.\
\ For example, $m=1000$ is chosen in the \\href{https://arxiv.org/pdf/1909.11261.pdf}{full-stack\
\ implementation} of Prism. New voter blocks are mined on each voter chain according\
\ to the longest chain rule. A voter block votes for a proposer block by containing\
\ a reference link to that proposer block, with the requirements that: (1) a vote\
\ is valid only if the voter block is in the longest chain of its voter tree;\
\ (2) each voter chain votes for one and only one proposer block at each level;\
\ (3) each voter block votes for all the proposer levels that have not been voted\
\ by its parent. The leader block at each level is the one that has the largest\
\ number of votes among all the proposer blocks at the same level (ties can be\
\ broken by the hash of the proposer blocks). The elected leader blocks then provide\
\ a unique ordering of the transaction blocks to form the final ledger. \n\n{\\\
sf Prism} also uses cryptographic sortition to prevent the adversary from focusing\
\ its mining power on a specific type of blocks or on a specific voter chain.\
\ A miner first forms a ``superblock\" containing $m+2$ parts: a transaction block,\
\ a proposer block and a voter block on the $i$-th voter tree ($1\\leq i \\leq\
\ m$). We say a superblock is successfully mined if \n\\begin{equation}\n \
\ Hash({\\sf nonce}, {\\sf superblock}) < T_{\\rm tx} + T_{\\rm prop} + m T_{\\\
rm v}. \n\\label{eq:sortition}\n\\end{equation}\nFurther, every successfully mined\
\ superblock is identified as a transaction block, a proposer block or a voter\
\ block based on the hash output: \n\n\n* identify the superblock as a proposer\
\ block if the hash output is less than $T_{\\rm prop}$;\n* identify the superblock\
\ as a transaction block if the hash output is in the range $[T_{\\rm prop}, T_{\\\
rm tx} + T_{\\rm prop})$;\n* identify the superblock as a voter block on the\
\ $i$-th voter tree ($1\\leq i \\leq m$) if the hash output is in the range $[T_{\\\
rm tx} + T_{\\rm prop} + (i-1) T_{\\rm v}, T_{\\rm tx} + T_{\\rm prop} + i T_{\\\
rm v} )$;"
- source_sentence: What is the role of the 2/3-GHOST function in the GRANDPA finality
gadget?
sentences:
- 'paper-title: GRANDPA: a Byzantine Finality Gadget
\subsection*{2.3 Preliminaries}
Network model : We will be using the partially synchronous network model introduced
by 7] and in particular the gossip network variant used in [5]. We assume that
any message sent or received by an honest participant reaches all honest participants
within time $T$, but possibly only after some Global Synchronisation Time GST.
Concretely, any message sent or received by some honest participant at time $t$
is received by all honest participants by time GST $+T$ at the latest.
Voters: For each voting step, there is a set of $n$ voters. We will frequently
need to assume that for each such step, at most $f<n / 3$ voters are Byzantine.
We need $n-f$ of voters to agree on finality. Whether or not block producers ever
vote, they will need to be participants who track the state of the protocol.
Votes: A vote is a block hash, together with some metadata such as round number
and the type of vote, such as prevote or precommit, all signed with a voter''s
private key.
Rounds: Each participant has their own idea of what is the current round number.
Every prevote and precommit has an associated round number. Honest voters only
vote once (for each type of vote) in each round and do not vote in earlier rounds
after later ones. Participants need to keep track of which block they see as currently
being the latest finalised block and an estimate of which block could have been
finalised in the last round.
For block $B$, we write chain $(B)$ for the chain whose head is $B$. The block
number, $n(B)$ of a block $B$ is the length of chain $(B)$. For blocks $B^{\prime}$
and $B$, we say $B$ is later than $B^{\prime}$ if it has a higher block number.
We write $B>B^{\prime}$ or that $B$ is descendant of $B^{\prime}$ for $B, B^{\prime}$
appearing in the same blockchain with $B^{\prime}$ later i.e. $B^{\prime} \in$
chain $(B)$ with $n(B)>n\left(B^{\prime}\right) . B \geq B^{\prime}$ and $B \leq
B^{\prime}$ are similar except allowing $B=B^{\prime}$. We write $B \sim B^{\prime}$
or $B$ and $B^{\prime}$ are on the same chain if $B<B^{\prime}, B=B^{\prime}$
or $B>B^{\prime}$; and $B \nsim B^{\prime}$ or $B$ and $B^{\prime}$ are not on
the same chain if there is no such chain.
Blocks are ordered as a tree with the genesis block as root. So any two blocks
have a common ancestor but two blocks not on the same chain do not have a common
descendant. A vote $v$ for a block $B$ by a voter $V$ is a message signed by $V$
containing the blockhash of $B$ and meta-information like the round numbers and
the type of vote.
A voter equivocates in a set of votes $S$ if they have cast multiple different
votes in $S$. We call a set $S$ of votes safe if the number of voters who equivocate
in $S$ is at most $f$. We say that $S$ has a supermajority for a block $B$ if
the set of voters who either have a vote for blocks $\geq B$ or equivocate in
$S$ has size at least $(n+f+1) / 2$. We count equivocations as votes for everything
so that observing a vote is monotonic, meaning that if $S \subset T$ then if $S$
has a supermajority for $B$ so does $T$, while being able to ignore yet more equivocating
votes from an equivocating voter.
For our finality gadget (GRANDPA) we use the ghost [13] eventual consensus algorithm
as $F$. The 2/3-GHOST function $g(S)$ takes a set $S$ of votes and returns the
block $B$ with highest block number such that $S$ has a supermajority for $B$.
If there is no such block, then it returns ''nil''. Note that, if $S$ is safe,
then we can compute $g(S)$ by starting at the genesis block and iteratively looking
for a child of our current block with a supermajority, which must be unique if
it exists. Thus we have:
Lemma 2.5. Let $T$ be a safe set of votes. Then'
- 'paper-title: Zexe: Enabling Decentralized Private Computation
In sum, proofs of predicates'' satisfiability are produced via a SNARK over $E_{\text
{BLS }}$, and proofs for the NP relation $\mathcal{R}_{\mathrm{e}}$ are produced
via a zkSNARK over $E_{\mathrm{CP}}$. The matching fields between the two curves
ensure that the former proofs can be efficiently verified.
Problem 3: Cocks-Pinch curves are costly. While the curve $E_{\mathrm{CP}}$ was
chosen to facilitate efficient checking of proofs over $E_{\mathrm{BLS}}$, the
curve $E_{\mathrm{CP}}$ is at least $2 \times$ more expensive (in time and space)
than $E_{\mathrm{BLS}}$ simply because $E_{\mathrm{CP}}$ ''s base field has about
twice as many bits as $E_{\mathrm{BLS}}$ ''s base field. Checks in the NP relation
$\mathcal{R}_{\mathrm{e}}$\\
that are not directly related to proof checking are now unnecessarily carried
over a less efficient curve.\\
Solution 3: split relations across two curves. We split $\mathcal{R}_{\mathrm{e}}$
into two NP relations $\mathcal{R}_{\mathrm{BLS}}$ and $\mathcal{R}_{\mathrm{CP}}$
(see Fig. 14), with the latter containing just the proof check and the former
containing all other checks. We can then use a zkSNARK over the curve $E_{\text
{BLS }}$ (an efficient curve) to produce proofs for $\mathcal{R}_{\mathrm{BLS}}$,
and a zkSNARK over $E_{\mathrm{CP}}$ (the less efficient curve) to produce proofs
for $\mathcal{R}_{\mathrm{CP}}$. This approach significantly reduces the running
time of DPC.Execute (producing proofs for the checks in $\mathcal{R}_{\mathrm{BLS}}$
is more efficient over $E_{\mathrm{BLS}}$ than over $E_{\mathrm{CP}}$ ), at the
expense of a modest increase in transaction size (a transaction now includes a
zkSNARK proof over $E_{\mathrm{BLS}}$ in addition to a proof over $E_{\mathrm{CP}}$
). An important technicality that must be addressed is that the foregoing split
relies on certain secret information to be shared across the NP relations, namely,
the identities of relevant predicates and the local data. We can store this information
in suitable commitments that are part of the NP instances for the two NP relations
(doing this efficiently requires some care as we discuss below).'
- 'paper-title: Ouroboros Praos: An adaptively-secure, semi-synchronous proof-of-stake
blockchain
where $\alpha_{\mathcal{H}}$ denotes the total relative stake of the honest parties.
Note that this bound applies to all static adversaries $\mathcal{A}$ that corrupt
no more than a $1-\alpha_{\mathcal{H}}$ fraction of all stake. With this in mind,
we define the dominant distribution as follows.\\
Definition 13 (The dominant distribution $\mathcal{D}_{\alpha}^{f}$ ). For two
parameters $f$ and $\alpha$, define $\mathcal{D}_{\alpha}^{f}$ to be the distribution
on strings $w \in\{0,1, \perp\}^{R}$ that independently assigns each $w_{i}$ so
that
\begin{align*}
p_{\perp} \triangleq \operatorname{Pr}\left[w_{i}\right. & =\perp]=1-f, \\
p_{0} \triangleq \operatorname{Pr}\left[w_{i}\right. & =0]=\phi(\alpha) \cdot(1-f),
\quad \text { and } \tag{9}\\
p_{1} \triangleq \operatorname{Pr}\left[w_{i}\right. & =1]=1-p_{\perp}-p_{0} .
\end{align*}
The distribution $\mathcal{D}_{\alpha}^{f}$ "dominates" $\mathcal{D}_{\mathcal{Z},
\mathcal{A}}^{f}$ for any static adversary $\mathcal{A}$ that corrupts no more
than a relative $1-\alpha$ share of the total stake, in the sense that nonempty
slots are more likely to be tainted under $\mathcal{D}_{\alpha}^{f}$ than they
are under $\mathcal{D}_{\mathcal{Z}, \mathcal{A}}^{f}$.
To make this relationship precise, we introduce the partial order $\preceq$ on
the set $\{\perp, 0,1\}$ so that $x \preceq y$ if and only if $x=y$ or $y=1$.
We extend this partial order to $\{\perp, 0,1\}^{R}$ by declaring $x_{1} \ldots
x_{R} \preceq y_{1} \ldots y_{R}$ if and only if $x_{i} \preceq y_{i}$ for each
$i$. Intuitively, the relationship $x \prec y$ asserts that $y$ is "more adversarial
than" $x$; concretely, any legal fork for $x$ is also a legal fork for $y$. Finally,
we define a notion of stochastic dominance for distributions on characteristic
strings, and $\alpha$-dominated adversaries.
Definition 14 (Stochastic dominance). We say that a subset $E \subseteq\{\perp,
0,1\}^{R}$ is monotone if $x \in E$ and $x \preceq y$ implies that $y \in E$.
Let $\mathcal{D}$ and $\mathcal{D}^{\prime}$ be two distributions on the set of
characteristic strings $\{\perp, 0,1\}^{R}$. Then we say that $\mathcal{D}^{\prime}$
dominates $\mathcal{D}$, written $\mathcal{D} \preceq \mathcal{D}^{\prime}$, if
$\operatorname{Pr}{ }_{\mathcal{D}}[E] \leq \operatorname{Pr}_{\mathcal{D}^{\prime}}[E]$
for every monotone set $E$. An adversary $\mathcal{A}$ is called $\alpha$-dominated
if the distribution $\mathcal{D}_{\mathcal{Z}, \mathcal{A}}^{f}$ that it induces
on the set of characteristic strings satisfies $\mathcal{D}_{\mathcal{Z}, \mathcal{A}}^{f}
\preceq \mathcal{D}_{\alpha}^{f}$.
As noted above, this notion of stochastic dominance is consistent with the chain-theoretic
definitions of interest, in the sense that failures of the abstract chain properties
form monotone events. We record this in the lemma below.'
- source_sentence: What does the paper conclude about the relationship between latency
and security in the Nakamoto Consensus protocol?
sentences:
- 'paper-title: Close Latency-Security Trade-off for the Nakamoto Consensus
Evidently, if the infinite sums in (2) and (10) are replaced by partial sums for
numerical evaluation, the resulting (tighter) security level remains unachievable.
\subsection*{3.1 Remarks}
Theorems 3.5 and 3.6 assume the delay $\Delta>0$. The bounds therein still apply
if we set $\Delta=0$, but are slightly looser than the bounds in Theorems 3.3
and 3.4 for the zero-delay case.
It is important to include the time of interest $s$ in Definitions 3.1 and 3.2.
The "bad events" for security breach depend on $s$ as well as the latency $t$.
These well-defined events are concerned with block mining times, not how blocks
form blockchains. ${ }^{3}$
We note that a number of previous analyses on the Nakamoto consensus assume a
finite lifespan of the protocol [1, 10], that is, a maximum round number is defined,
at which round the protocol terminates. The probability of consistency depends
on the maximum round number. In contrast, this paper does not assume a finite
lifespan. Theorem 3.5 states that, barring a small probability event, confirmed
blocks remain permanently in all miners'' longest blockchains into the arbitrary
future.
Even though we provide the same security guarantee for every blockchain after
the confirmation latency $t$, no one can simultaneously guarantee the same for
all blocks that will ever be confirmed.
\footnotetext{${ }^{3}$ To be rigorous, we do not make claims such as "the blockchain/protocol/system
satisfies consistency or liveness properties with probability ..." because those
properties themselves are not events in the probability space defined here.
}
\includegraphics[max width=\textwidth, center]{2025_01_02_447c9a776bd74bcc1f99g-04}
Figure 1: Bitcoin''s latency-security trade-off with $\alpha+\beta=$ $1 / 600$
blocks per second and $\Delta=10$ seconds.
This is a simple consequence of Murphy''s Law: If an adversary keeps trying new
episodes of attacks, with probability 1 a bad event will eventually occur to revert
some confirmed honest blocks.
For technical convenience, we regard a block in a miner''s longest blockchain
to be confirmed after a certain amount of time elapses since the block is mined
or enters the miner''s view. Nakamoto [22] originally proposed confirming a block
after it is sufficiently deep in an honest miner''s longest blockchain. We believe
both confirmation rules are easy to use in practice. And the two confirmation
rules imply each other in probability (see Appendix A for further discussion).
\subsection*{3.2 Numerical Examples}
The latency-security trade-off under several different sets of parameters is plotted
in Figure 1. The mining rate is set to Bitcoin''s one block per 600 seconds, or
$\alpha+\beta=1 / 600$ blocks/second. The propagation delay bound is assumed to
be $\Delta=10$ seconds. The latency upper and lower bounds are computed using
Theorems 3.5 and 3.6, respectively. In Figure 1, all bounds appear to be exponential
for all but very small latency and high error probabilities. This implies the
exponential bound (7) is a good approximation of (5) in Theorem 3.5 for the typical
range of parameters of interest here.
It is instructive to examine concrete data points in Figure 1: If the adversarial
share of the total network mining rate is $10 \%$ $(\alpha: \beta=9: 1)$, then
a confirmation time of four hours is sufficient to achieve $10^{-3}$ security
level, and a ten-hour confirmation achieves $10^{-9}$ security level. These results
are about two hours away from the corresponding lower bounds. Also, for every
additional hour of latency, the security improves by a factor of approximately
20 . If the adversarial share of the mining rate increases to $25 \%(\alpha: \beta=3:
1)$, then 10 hours 40 minutes and 28 hours 45 minutes of confirmation times achieve
$10^{-3}$ and $10^{-9}$ security levels, respectively, and the gap between the
upper and lower bounds is between five and seven hours. In general, the gap is
proportionally insignificant at high security levels but can be otherwise at low
security levels. For given mining rates, the gaps are similar at different security
levels. This indicates the lower bound (10) is also approximately exponential
with a slightly steeper exponent than that of the upper bound.'
- "paper-title: Ledger Combiners for Fast Settlement\n\n$$\n\\begin{aligned}\n\\\
delta\\left(\\operatorname{PoW}_{p}^{m}(x), \\mathrm{IPoW}_{p / m}^{m}(x)\\right)\
\ & =\\frac{1}{2} \\sum_{s \\in\\{0,1\\}^{m}}\\left|\\operatorname{Pr}\\left[\\\
operatorname{PoW}_{p}^{m}(x)=s\\right]-\\operatorname{Pr}\\left[\\operatorname{IPoW}_{p\
\ / m}^{m}(x)=s\\right]\\right| \\\\\n& =\\sum_{\\substack{s \\in\\{0,1)^{m} \\\
\\\n\\mathrm{hw}(s)=1}}\\left(\\operatorname{Pr}\\left[\\operatorname{PoW}_{p}^{m}(x)=s\\\
right]-\\operatorname{Pr}\\left[\\operatorname{IPoW}_{p / m}^{m}(x)=s\\right]\\\
right) \\\\\n& \\leq m \\cdot\\left[\\frac{p}{m}-\\frac{p}{m}\\left(1-\\frac{p}{m}\\\
right)^{m-1}\\right] \\leq p[1-(1-p)]=p^{2}\n\\end{aligned}\n$$\n\nas desired,\
\ where the last inequality follows by Bernoulli inequality.\n\nThe above lemma\
\ already justifies the use of $\\mathrm{PoW}_{p}^{m}$ for achieving subindependence\
\ in practical scenarios. To observe this, note that the use of $\\mathrm{IPoW}_{p\
\ / m}^{m}$ would lead to full independence of the individual PoW lotteries, and\
\ by Lemma 7 the real execution with $\\mathrm{PoW}_{p}^{m}$ will only differ\
\ from this ideal behavior with probability at most $Q \\cdot p^{2}$, where $Q$\
\ is the total number of PoW-queries. With current values of $p \\approx 10^{-22}$\
\ in e.g., Bitcoin ${ }^{2}$, and the block creation time adjusting to 10 minutes,\
\ this difference would manifest on expectation in about $10^{18}$ years. Note\
\ that any future increase of the total mining difficulty while maintaining the\
\ block creation time would only increase this period.\n\nNonetheless, in Appendix\
\ F we give a more detailed analysis of $\\mathrm{PoW}_{p}^{m}$ that shows that,\
\ loosely speaking, $m$ parallel executions of Bitcoin using PoW ${ }_{p}^{m}$\
\ as their shared PoW oracle achieve $\\varepsilon$-subindependence for $\\varepsilon$\
\ negligible in the security parameter.\n\n\\subsection*{4.2 Realizing Rank via\
\ Timestamped Blockchains}\nAn important consideration when deploying our virtual\
\ ledger construction over existing blockchains is how to realize the notion of\
\ rank. We note that typical Nakamoto-style PoS blockchains (e.g., the Ouroboros\
\ family, Snow White) assume a common notion of time among the participants and\
\ explicitly label blocks with slot numbers with a direct correspondence to absolute\
\ time. These slot numbers (or, preferably, a notion of common time associated\
\ with each slot number) directly afford a notion of rank that provides the desired\
\ persistence and liveness guarantees. To formalize this property, we introduce\
\ the notion of a timestamped blockchain.\n\nDefinition 11. A timestamped blockchain\
\ is one satisfying the following conventions:\n\n\\begin{itemize}\n \\item Block\
\ timestamps. Every block contains a declared timestamp.\n \\item Monotonicity.\
\ In order for a block to be considered valid, its timestamp can be no less than\
\ the timestamps of all prior blocks in the blockchain. (Thus valid blockchains\
\ consist of blocks in monotonically increasing order.)\n\\end{itemize}\n\nInformally,\
\ we say that an algorithm is a timestamped blockchain algorithm if it calls for\
\ participants to broadcast timestamped blockchains and to \"respect timestamps.\"\
\ More specifically, the algorithm satisfies the following:\n\n\\begin{itemize}\n\
\ \\item Faithful honest timestamping. Honest participants always post blocks\
\ with timestamps determined by their local clocks.\n \\item Ignore future blocks.\
\ Honest participants ignore blocks that contain a timestamp which is greater\
\ than their local time by more than a fixed constant. (These blocks might be\
\ considered later when the local clock of the participant \"catches up\" with\
\ the timestamp.)\n\\end{itemize}"
- "paper-title: A Scalable Proof-of-Stake Blockchain in the Open Setting * \\\\\
\ (or, How to Mimic Nakamoto's Design via Proof-of-Stake)\n\nLet $\\ell$ be the\
\ length of core-chain $\\mathcal{C}$. In our design, only the elected PoS-players\
\ are allowed to generate new block-cores (to extend the core-chain). Now, each\
\ registered PoS-player P will work on the right \"context\" which consists of\
\ the latest block-core in the longest corechain and the current time; formally\
\ context $:=\\left\\langle h^{\\text {prev }}\\right.$, round $\\rangle$ where\
\ $\\mathcal{C}[\\ell]$ is the latest blockcore in the longest core-chain $\\\
mathcal{C}$, and $h^{\\text {prev }}$ is the identity returned by the functionality\
\ $\\mathcal{F}_{\\text {rCERT }}$ for $\\mathcal{C}[\\ell]$, and round denotes\
\ the current time. The PoS-player P may query $\\mathcal{F}_{\\text {rCERT }}$\
\ by command (Elect, P , context, $\\mathcal{C}$ ) to see if he is selected to\
\ extend $\\mathcal{C}$. If the PoS-player P is selected (with certain probability\
\ $p$ ), he would receive a message (Elected, $\\mathrm{P}, h, \\sigma, \\mathrm{~b}$\
\ ) from $\\mathcal{F}_{\\text {rCERT }}$ such that $\\mathrm{b}=1$. Once receiving\
\ the signature $\\sigma$ from the functionality, the PoS-player P defines a new\
\ block-core $B:=\\left\\langle\\left\\langle h^{\\text {prev }}, h\\right.\\\
right.$, round $\\left.\\rangle, \\mathrm{P}, \\sigma\\right\\rangle$, updates\
\ his local core-chain $\\mathcal{C}$ and then broadcasts the local core-chain\
\ to the network. Please refer to Figure 3 for more details of our core-chain\
\ protocol.\n\nNote that here PoS-players have access to the functionality $\\\
mathcal{F}_{\\text {rCERT }}$. The players need to register to the functionality\
\ $\\mathcal{F}_{\\text {rCERT }}$ before querying the functionality.\n\nThe best\
\ core-chain strategy. Our proof-of-stake core-chain protocol $\\Pi^{\\text {core\
\ }}$ uses the subroutine BestCore to single out the best valid core-chain from\
\ a set of core-chains. Now we describe the rules of selecting the best core-chain.\
\ Roughly speaking, a core-chain is the best one if it is the current longest\
\ valid core-chain. The BestCore subroutine takes as input, a core-chain set $\\\
mathbb{C}^{\\prime}$ and the current time information round'. Intuitively, the\
\ subroutine validates all $\\mathcal{C} \\in \\mathbb{C}^{\\prime}$, then finds\
\ the valid longest core-chain.\n\nIn more detail, BestCore proceeds as follows.\
\ On input the current set of core-chains $\\mathbb{C}^{\\prime}$ and the current\
\ time information round', and for each core-chain $\\mathcal{C}$, the subroutine\
\ then evaluates every block-core of the core-chain $\\mathcal{C}$ sequentially.\
\ Let $\\ell$ be the length of $\\mathcal{C}$. Starting from the head of $\\mathcal{C}$,\
\ for every block-core $\\mathcal{C}[i]$, for all $i \\in[\\ell]$, in the core-chain\
\ $\\mathcal{C}$, the BestCore subroutine (1) ensures that $\\mathcal{C}[i]$ is\
\ linked to the previous block-core $\\mathcal{C}[i-1]$ correctly, and (2) tests\
\ if the\n\n\\section*{Protocol $\\Pi^{\\text {core }}$}\nInitially, a set $\\\
mathcal{P}_{0}$ of players are registered to the functionality $\\mathcal{F}_{\\\
text {rCERT }}$, where $\\mathcal{P}_{0} \\subseteq \\mathcal{P}$. Initially,\
\ for each $\\mathrm{P} \\in \\mathcal{P}$, set $\\mathcal{C}:=\\emptyset$, and\
\ state $:=\\emptyset$.\n\nUpon receiving message (Input-Stake, P ) from the environment\
\ $z$ at round round, the PoS-player $\\mathrm{P} \\in$ $\\mathcal{P}$, with local\
\ state state, proceeds as follows.\n\n\\begin{enumerate}\n \\item Select the\
\ best local PoS core-chain:\n\\end{enumerate}"
- source_sentence: What is the difference between absolute settlement and relative
settlement for transactions in a ledger?
sentences:
- 'paper-title: Ledger Combiners for Fast Settlement
Since the above requirements are formulated independently for each $t$, it is
well-defined to treat $\mathrm{C}[\cdot]$ as operating on ledgers rather than
dynamic ledgers; we sometimes overload the notation in this sense.
Looking ahead, our amplification combiner will consider $\mathrm{t}_{\mathrm{C}}\left(\mathbf{L}_{1}^{(t)},
\ldots, \mathbf{L}_{m}^{(t)}\right)=\bigcup_{i} \mathbf{L}_{i}^{(t)}$ along with
two related definitions of $\mathrm{a}_{\mathrm{C}}$ :
$$
\mathrm{a}_{\mathrm{C}}\left(A_{1}^{(t)}, \ldots, A_{m}^{(t)}\right)=\bigcup_{i}
A_{i}^{(t)} \quad \text { and } \quad \mathrm{a}_{\mathrm{C}}\left(A_{1}^{(t)},
\ldots, A_{m}^{(t)}\right)=\bigcap_{i} A_{i}^{(t)}
$$
see Section 3. The robust combiner will adopt a more sophisticated notion of $t_{c}$;
see Section 5 . In each of these cases, the important structural properties of
the construction are captured by the rank function $r_{C}$.
\subsection*{2.3 Transaction Validity and Settlement}
In the discussion below, we assume a general notion of transaction validity that
can be decided inductively: given a ledger $\mathbf{L}$, the validity of a transaction
$t x \in \mathbf{L}$ is determined by the transactions in the state $\mathbf{L}\lceil\operatorname{tx}\rceil$
of $\mathbf{L}$ up to tx and their ordering. Intuitively, only valid transactions
are then accounted for when interpreting the state of the ledger on the application
level. The canonical example of such a validity predicate in the case of so-called
UTXO transactions is formalized for completeness in Appendix B. Note that protocols
such as Bitcoin allow only valid transactions to enter the ledger; as the Bitcoin
ledger is represented by a simple chain it is possible to evaluate the validity
predicate upon block creation for each included transaction. This may not be the
case for more general ledgers, such as the result of applying one of our combiners
or various DAG-based constructions.
While we focus our analysis on persistence and liveness as given in Definition
3, our broader goal is to study settlement. Intuitively, settlement is the delay
necessary to ensure that a transaction included in some $A^{(t)}$ enters the dynamic
ledger and, furthermore, that its validity stabilizes for all future times.
Definition 5 (Absolute settlement). For a dynamic ledger $\mathbf{D} \stackrel{\text
{ def }}{=} \mathbf{L}^{(0)}, \mathbf{L}^{(1)}, \ldots$ we say that a transaction
$t x \in$ $A^{(\tau)} \cap \mathbf{L}^{(t)}($ for $\tau \leq t)$ is (absolutely)
settled at time $t$ iffor all $\ell \geq t$ we have: (i) $\mathbf{L}^{(t)}\lceil\mathrm{tx}\rceil
\subseteq \mathbf{L}^{(\ell)}$, (ii) the linear orders $<_{\mathbf{L}^{(t)}}$
and $<_{\mathbf{L}^{(t)}}$ agree on $\mathbf{L}^{(t)}\lceil\mathrm{tx}\rceil$,
and (iii) for any $\mathrm{tx}^{\prime} \in \mathbf{L}^{(e)}$ such that $\mathrm{tx}^{\prime}{<_{\mathbf{L}}(t)}
\mathrm{tx}$ we have $\mathrm{tx}^{\prime} \in \mathbf{L}^{(t)}\lceil\mathrm{tx}\rceil$.
Note that for any absolutely settled transaction, its validity is determined and
it is guaranteed to remain unchanged in the future.
It will be useful to also consider a weaker notion of relative settlement of a
transaction: Intuitively, tx is relatively settled at time $t$ if we have the
guarantee that no (conflicting) transaction $\mathrm{tx}^{\prime}$ that is not
part of the ledger at time $t$ can possibly eventually precede $t x$ in the ledger
ordering.'
- "paper-title: Casper the Friendly Finality Gadget\n\n\\documentclass[10pt]{article}\n\
\\usepackage[utf8]{inputenc}\n\\usepackage[T1]{fontenc}\n\\usepackage{amsmath}\n\
\\usepackage{amsfonts}\n\\usepackage{amssymb}\n\\usepackage[version=4]{mhchem}\n\
\\usepackage{stmaryrd}\n\\usepackage{graphicx}\n\\usepackage[export]{adjustbox}\n\
\\graphicspath{ {./images/} }\n\\usepackage{hyperref}\n\\hypersetup{colorlinks=true,\
\ linkcolor=blue, filecolor=magenta, urlcolor=cyan,}\n\\urlstyle{same}\n\n\\title{Casper\
\ the Friendly Finality Gadget }\n\n\\author{Vitalik Buterin and Virgil Griffith\\\
\\\nEthereum Foundation}\n\\date{}\n\n\n%New command to display footnote whose\
\ markers will always be hidden\n\\let\\svthefootnote\\thefootnote\n\\newcommand\\\
blfootnotetext[1]{%\n \\let\\thefootnote\\relax\\footnote{#1}%\n \\addtocounter{footnote}{-1}%\n\
\ \\let\\thefootnote\\svthefootnote%\n}\n\n%Overriding the \\footnotetext command\
\ to hide the marker if its value is `0`\n\\let\\svfootnotetext\\footnotetext\n\
\\renewcommand\\footnotetext[2][?]{%\n \\if\\relax#1\\relax%\n \\ifnum\\value{footnote}=0\\\
blfootnotetext{#2}\\else\\svfootnotetext{#2}\\fi%\n \\else%\n \\if?#1\\ifnum\\\
value{footnote}=0\\blfootnotetext{#2}\\else\\svfootnotetext{#2}\\fi%\n \\else\\\
svfootnotetext[#1]{#2}\\fi%\n \\fi\n}\n\n\\begin{document}\n\\maketitle\n\n\n\
\\begin{abstract}\nWe introduce Casper, a proof of stake-based finality system\
\ which overlays an existing proof of work blockchain. Casper is a partial consensus\
\ mechanism combining proof of stake algorithm research and Byzantine fault tolerant\
\ consensus theory. We introduce our system, prove some desirable features, and\
\ show defenses against long range revisions and catastrophic crashes. The Casper\
\ overlay provides almost any proof of work chain with additional protections\
\ against block reversions.\n\\end{abstract}\n\n\\section*{1. Introduction}\n\
Over the past few years there has been considerable research into \"proof of stake\"\
\ (PoS) based blockchain consensus algorithms. In a PoS system, a blockchain appends\
\ and agrees on new blocks through a process where anyone who holds coins inside\
\ of the system can participate, and the influence an agent has is proportional\
\ to the number of coins (or \"stake\") it holds. This is a vastly more efficient\
\ alternative to proof of work (PoW) \"mining\" and enables blockchains to operate\
\ without mining's high hardware and electricity costs.\\\\[0pt]\nThere are two\
\ major schools of thought in PoS design. The first, chain-based proof of stake[1,\
\ 2], mimics proof of work mechanics and features a chain of blocks and simulates\
\ mining by pseudorandomly assigning the right to create new blocks to stakeholders.\
\ This includes Peercoin[3], Blackcoin[4], and Iddo Bentov's work[5].\\\\[0pt]\n\
The other school, Byzantine fault tolerant (BFT) based proof of stake, is based\
\ on a thirty-year-old body of research into BFT consensus algorithms such as\
\ PBFT[6]. BFT algorithms typically have proven mathematical properties; for example,\
\ one can usually mathematically prove that as long as $>\\frac{2}{3}$ of protocol\
\ participants are following the protocol honestly, then, regardless of network\
\ latency, the algorithm cannot finalize conflicting blocks. Repurposing BFT algorithms\
\ for proof of stake was first introduced by Tendermint[7], and has modern inspirations\
\ such as [8]. Casper follows this BFT tradition, though with some modifications.\n\
\n\\subsection*{1.1. Our Work}\nCasper the Friendly Finality Gadget is an overlay\
\ atop a proposal mechanism-a mechanism which proposes blocks ${ }^{1}$. Casper\
\ is responsible for finalizing these blocks, essentially selecting a unique chain\
\ which represents the canonical transactions of the ledger. Casper provides safety,\
\ but liveness depends on the chosen proposal mechanism. That is, if attackers\
\ wholly control the proposal mechanism, Casper protects against finalizing two\
\ conflicting checkpoints, but the attackers could prevent Casper from finalizing\
\ any future checkpoints.\\\\\nCasper introduces several new features that BFT\
\ algorithms do not necessarily support:"
- 'paper-title: Bitcoin and Cryptocurrency Technologies
Interestingly, these concerns have an analogy in the realm of voting. It''s illegal
in the United States and many other nations for individuals to sell their vote.
Arguably participating in a pool controlled by someone else is akin to selling
your vote in the Bitcoin consensus protocol.
Technical requirements for pools. Recall that mining pools appear to be an emergent
phenomenon. There''s no evidence that Satoshi was thinking of mining pools at
the time of Bitcoin''s original design. It wasn''t apparent for a few years that
efficient pools could be run between many individuals who don''t know or trust
each other.
As we saw in Chapter 5, mining pools typically work by designating a pool operator
with a well-known public key. Each of the participating miners mines as usual
but sends in shares to the pool operator. These shares are "near misses" or "partial
solutions" which would be valid solutions at a lower difficulty level. This shows
the pool operator how much work the miner is performing. Whenever one of the pool
participants finds a valid block, the pool operator then distributes the rewards
amongst the pool participants based on the number of shares they have submitted.
As we discussed in Chapter 5, there are many formulas for dividing the revenue
up, but all mining pools follow this basic structure.
The existence of pools thus relies on at least two technical properties of Bitcoin.
The first is that it''s easy for a miner to prove (probabilistically) how much
work they are doing by submitting shares. By choosing a low enough threshold for
shares, miners can easily prove how much work they are performing with arbitrary
precision regardless of the actual difficulty of finding an valid block. This
facet of mining puzzles appears difficult to change, given that we need a puzzle
that can be created with arbitrary difficulty.
Second, pool members can easily prove to the pool operator that they''re following
the rules and working to find valid blocks which would reward the pool as a whole.
This works because the pool''s public key is committed to in the coinbase transaction
included in the block''s Merkle tree of transactions. Once a miner finds a block
or even a share, they can''t change which public key is the recipient of the newly
minted coins.
Block discarding attacks. There is one weakness in this scheme for implementing
mining pools: there is nothing to to enforce that participating miners actually
submit valid blocks to the pool manager in the event that they find them. Suppose
that there''s a pool member that''s upset with a large mining pool. They can participate
in the pool by mining and submitting shares just like normal, but in the event
that they actually find a valid block that would reward the pool they simply discard
it and don''t tell the pool operator about it.
This attack reduces the pool''s overall mining power as none of the attacker''s
work is contributing towards finding valid blocks. However the attacker will still
be rewarded as they appear to be submitting valid shares and simply getting unlucky
to not find any valid blocks. If the mining pool is designed to be revenue-neutral
(that is, all mining rewards are redistributed back to participants) then this
attack can cause the pool to run at a loss.
This attack is sometimes called a vigilante or sabotage attack and is considered
a form of vandalism because the attack appears to be costly for both the attacker
and the pool. The attacker loses money because every block they discard would
have led to some proportion of the block rewards being returned to them. Of course,
the attacker still gets rewards for other puzzle solutions that are found.
It appears that a rational attacker wouldn''t employ this strategy, since they
would lose money without gaining anything tangible. It turns out (quite surprisingly)
that there are cases where this strategy can be profitable, as discussed in the
box below. But in any case, we want to design an entirely new mining puzzle formulation
that ensures this strategy is always profitable.
Sidebar: block discarding attacks between pools. People assumed for years that
it can''t be profitable for a participant to discard valid blocks found on behalf
of the pool. It turns out this strategy can be profitable if one mining pool uses
it to attack another. This was proposed apocryphally many times and first thoroughly
analyzed in a paper by Ittay Eyal in 2015.
Let''s consider a simple case: suppose two mining pools, $A$ and $B$, each have
$50 \%$ of the total mining capacity. Now suppose B uses half of its mining power
( $25 \%$ of the total capacity) to mine as a member in pool A, but discards all
blocks found. We can show, in a simplified model, that B will now earns $5 / 9$
of the total rewards, greater than the $50 \%$ it would earn by mining normally.
In this simple case, dedicating half of its mining power to attacking can be shown
to be the optimal strategy for pool B.'
pipeline_tag: sentence-similarity
library_name: sentence-transformers
metrics:
- cosine_accuracy@1
- cosine_accuracy@3
- cosine_accuracy@5
- cosine_accuracy@10
- cosine_precision@1
- cosine_precision@3
- cosine_precision@5
- cosine_precision@10
- cosine_recall@1
- cosine_recall@3
- cosine_recall@5
- cosine_recall@10
- cosine_ndcg@10
- cosine_mrr@10
- cosine_map@100
model-index:
- name: SentenceTransformer based on BAAI/bge-base-en-v1.5
results:
- task:
type: information-retrieval
name: Information Retrieval
dataset:
name: dim 768
type: dim_768
metrics:
- type: cosine_accuracy@1
value: 0.5
name: Cosine Accuracy@1
- type: cosine_accuracy@3
value: 0.7857142857142857
name: Cosine Accuracy@3
- type: cosine_accuracy@5
value: 0.8571428571428571
name: Cosine Accuracy@5
- type: cosine_accuracy@10
value: 0.8571428571428571
name: Cosine Accuracy@10
- type: cosine_precision@1
value: 0.5
name: Cosine Precision@1
- type: cosine_precision@3
value: 0.26190476190476186
name: Cosine Precision@3
- type: cosine_precision@5
value: 0.17142857142857146
name: Cosine Precision@5
- type: cosine_precision@10
value: 0.08571428571428573
name: Cosine Precision@10
- type: cosine_recall@1
value: 0.5
name: Cosine Recall@1
- type: cosine_recall@3
value: 0.7857142857142857
name: Cosine Recall@3
- type: cosine_recall@5
value: 0.8571428571428571
name: Cosine Recall@5
- type: cosine_recall@10
value: 0.8571428571428571
name: Cosine Recall@10
- type: cosine_ndcg@10
value: 0.7032219246239031
name: Cosine Ndcg@10
- type: cosine_mrr@10
value: 0.6511904761904762
name: Cosine Mrr@10
- type: cosine_map@100
value: 0.6553083095766022
name: Cosine Map@100
- task:
type: information-retrieval
name: Information Retrieval
dataset:
name: dim 512
type: dim_512
metrics:
- type: cosine_accuracy@1
value: 0.5714285714285714
name: Cosine Accuracy@1
- type: cosine_accuracy@3
value: 0.7857142857142857
name: Cosine Accuracy@3
- type: cosine_accuracy@5
value: 0.8214285714285714
name: Cosine Accuracy@5
- type: cosine_accuracy@10
value: 0.8571428571428571
name: Cosine Accuracy@10
- type: cosine_precision@1
value: 0.5714285714285714
name: Cosine Precision@1
- type: cosine_precision@3
value: 0.26190476190476186
name: Cosine Precision@3
- type: cosine_precision@5
value: 0.1642857142857143
name: Cosine Precision@5
- type: cosine_precision@10
value: 0.08571428571428573
name: Cosine Precision@10
- type: cosine_recall@1
value: 0.5714285714285714
name: Cosine Recall@1
- type: cosine_recall@3
value: 0.7857142857142857
name: Cosine Recall@3
- type: cosine_recall@5
value: 0.8214285714285714
name: Cosine Recall@5
- type: cosine_recall@10
value: 0.8571428571428571
name: Cosine Recall@10
- type: cosine_ndcg@10
value: 0.7276726753008987
name: Cosine Ndcg@10
- type: cosine_mrr@10
value: 0.6848639455782314
name: Cosine Mrr@10
- type: cosine_map@100
value: 0.6886316064887493
name: Cosine Map@100
- task:
type: information-retrieval
name: Information Retrieval
dataset:
name: dim 256
type: dim_256
metrics:
- type: cosine_accuracy@1
value: 0.5714285714285714
name: Cosine Accuracy@1
- type: cosine_accuracy@3
value: 0.7857142857142857
name: Cosine Accuracy@3
- type: cosine_accuracy@5
value: 0.8214285714285714
name: Cosine Accuracy@5
- type: cosine_accuracy@10
value: 0.8571428571428571
name: Cosine Accuracy@10
- type: cosine_precision@1
value: 0.5714285714285714
name: Cosine Precision@1
- type: cosine_precision@3
value: 0.26190476190476186
name: Cosine Precision@3
- type: cosine_precision@5
value: 0.1642857142857143
name: Cosine Precision@5
- type: cosine_precision@10
value: 0.08571428571428573
name: Cosine Precision@10
- type: cosine_recall@1
value: 0.5714285714285714
name: Cosine Recall@1
- type: cosine_recall@3
value: 0.7857142857142857
name: Cosine Recall@3
- type: cosine_recall@5
value: 0.8214285714285714
name: Cosine Recall@5
- type: cosine_recall@10
value: 0.8571428571428571
name: Cosine Recall@10
- type: cosine_ndcg@10
value: 0.7284895986499949
name: Cosine Ndcg@10
- type: cosine_mrr@10
value: 0.6857142857142858
name: Cosine Mrr@10
- type: cosine_map@100
value: 0.6893267651888342
name: Cosine Map@100
- task:
type: information-retrieval
name: Information Retrieval
dataset:
name: dim 128
type: dim_128
metrics:
- type: cosine_accuracy@1
value: 0.5
name: Cosine Accuracy@1
- type: cosine_accuracy@3
value: 0.75
name: Cosine Accuracy@3
- type: cosine_accuracy@5
value: 0.8214285714285714
name: Cosine Accuracy@5
- type: cosine_accuracy@10
value: 0.8571428571428571
name: Cosine Accuracy@10
- type: cosine_precision@1
value: 0.5
name: Cosine Precision@1
- type: cosine_precision@3
value: 0.24999999999999997
name: Cosine Precision@3
- type: cosine_precision@5
value: 0.1642857142857143
name: Cosine Precision@5
- type: cosine_precision@10
value: 0.08571428571428573
name: Cosine Precision@10
- type: cosine_recall@1
value: 0.5
name: Cosine Recall@1
- type: cosine_recall@3
value: 0.75
name: Cosine Recall@3
- type: cosine_recall@5
value: 0.8214285714285714
name: Cosine Recall@5
- type: cosine_recall@10
value: 0.8571428571428571
name: Cosine Recall@10
- type: cosine_ndcg@10
value: 0.6935204558400861
name: Cosine Ndcg@10
- type: cosine_mrr@10
value: 0.6395833333333334
name: Cosine Mrr@10
- type: cosine_map@100
value: 0.6425405844155845
name: Cosine Map@100
- task:
type: information-retrieval
name: Information Retrieval
dataset:
name: dim 64
type: dim_64
metrics:
- type: cosine_accuracy@1
value: 0.42857142857142855
name: Cosine Accuracy@1
- type: cosine_accuracy@3
value: 0.6785714285714286
name: Cosine Accuracy@3
- type: cosine_accuracy@5
value: 0.75
name: Cosine Accuracy@5
- type: cosine_accuracy@10
value: 0.8214285714285714
name: Cosine Accuracy@10
- type: cosine_precision@1
value: 0.42857142857142855
name: Cosine Precision@1
- type: cosine_precision@3
value: 0.22619047619047614
name: Cosine Precision@3
- type: cosine_precision@5
value: 0.15000000000000005
name: Cosine Precision@5
- type: cosine_precision@10
value: 0.08214285714285716
name: Cosine Precision@10
- type: cosine_recall@1
value: 0.42857142857142855
name: Cosine Recall@1
- type: cosine_recall@3
value: 0.6785714285714286
name: Cosine Recall@3
- type: cosine_recall@5
value: 0.75
name: Cosine Recall@5
- type: cosine_recall@10
value: 0.8214285714285714
name: Cosine Recall@10
- type: cosine_ndcg@10
value: 0.631592589549331
name: Cosine Ndcg@10
- type: cosine_mrr@10
value: 0.5696428571428572
name: Cosine Mrr@10
- type: cosine_map@100
value: 0.5757306413556414
name: Cosine Map@100
---
# SentenceTransformer based on BAAI/bge-base-en-v1.5
This is a [sentence-transformers](https://www.SBERT.net) model finetuned from [BAAI/bge-base-en-v1.5](https://huggingface.co/BAAI/bge-base-en-v1.5) on the json dataset. It maps sentences & paragraphs to a 768-dimensional dense vector space and can be used for semantic textual similarity, semantic search, paraphrase mining, text classification, clustering, and more.
## Model Details
### Model Description
- **Model Type:** Sentence Transformer
- **Base model:** [BAAI/bge-base-en-v1.5](https://huggingface.co/BAAI/bge-base-en-v1.5) <!-- at revision a5beb1e3e68b9ab74eb54cfd186867f64f240e1a -->
- **Maximum Sequence Length:** 512 tokens
- **Output Dimensionality:** 768 dimensions
- **Similarity Function:** Cosine Similarity
- **Training Dataset:**
- json
<!-- - **Language:** Unknown -->
<!-- - **License:** Unknown -->
### Model Sources
- **Documentation:** [Sentence Transformers Documentation](https://sbert.net)
- **Repository:** [Sentence Transformers on GitHub](https://github.com/UKPLab/sentence-transformers)
- **Hugging Face:** [Sentence Transformers on Hugging Face](https://huggingface.co/models?library=sentence-transformers)
### Full Model Architecture
```
SentenceTransformer(
(0): Transformer({'max_seq_length': 512, 'do_lower_case': True}) with Transformer model: BertModel
(1): Pooling({'word_embedding_dimension': 768, 'pooling_mode_cls_token': True, 'pooling_mode_mean_tokens': False, 'pooling_mode_max_tokens': False, 'pooling_mode_mean_sqrt_len_tokens': False, 'pooling_mode_weightedmean_tokens': False, 'pooling_mode_lasttoken': False, 'include_prompt': True})
(2): Normalize()
)
```
## Usage
### Direct Usage (Sentence Transformers)
First install the Sentence Transformers library:
```bash
pip install -U sentence-transformers
```
Then you can load this model and run inference.
```python
from sentence_transformers import SentenceTransformer
# Download from the 🤗 Hub
model = SentenceTransformer("mahsaBa76/bge-base-custom-matryoshka")
# Run inference
sentences = [
'What is the difference between absolute settlement and relative settlement for transactions in a ledger?',
'paper-title: Ledger Combiners for Fast Settlement\n\nSince the above requirements are formulated independently for each $t$, it is well-defined to treat $\\mathrm{C}[\\cdot]$ as operating on ledgers rather than dynamic ledgers; we sometimes overload the notation in this sense.\n\nLooking ahead, our amplification combiner will consider $\\mathrm{t}_{\\mathrm{C}}\\left(\\mathbf{L}_{1}^{(t)}, \\ldots, \\mathbf{L}_{m}^{(t)}\\right)=\\bigcup_{i} \\mathbf{L}_{i}^{(t)}$ along with two related definitions of $\\mathrm{a}_{\\mathrm{C}}$ :\n\n$$\n\\mathrm{a}_{\\mathrm{C}}\\left(A_{1}^{(t)}, \\ldots, A_{m}^{(t)}\\right)=\\bigcup_{i} A_{i}^{(t)} \\quad \\text { and } \\quad \\mathrm{a}_{\\mathrm{C}}\\left(A_{1}^{(t)}, \\ldots, A_{m}^{(t)}\\right)=\\bigcap_{i} A_{i}^{(t)}\n$$\n\nsee Section 3. The robust combiner will adopt a more sophisticated notion of $t_{c}$; see Section 5 . In each of these cases, the important structural properties of the construction are captured by the rank function $r_{C}$.\n\n\\subsection*{2.3 Transaction Validity and Settlement}\nIn the discussion below, we assume a general notion of transaction validity that can be decided inductively: given a ledger $\\mathbf{L}$, the validity of a transaction $t x \\in \\mathbf{L}$ is determined by the transactions in the state $\\mathbf{L}\\lceil\\operatorname{tx}\\rceil$ of $\\mathbf{L}$ up to tx and their ordering. Intuitively, only valid transactions are then accounted for when interpreting the state of the ledger on the application level. The canonical example of such a validity predicate in the case of so-called UTXO transactions is formalized for completeness in Appendix B. Note that protocols such as Bitcoin allow only valid transactions to enter the ledger; as the Bitcoin ledger is represented by a simple chain it is possible to evaluate the validity predicate upon block creation for each included transaction. This may not be the case for more general ledgers, such as the result of applying one of our combiners or various DAG-based constructions.\n\nWhile we focus our analysis on persistence and liveness as given in Definition 3, our broader goal is to study settlement. Intuitively, settlement is the delay necessary to ensure that a transaction included in some $A^{(t)}$ enters the dynamic ledger and, furthermore, that its validity stabilizes for all future times.\n\nDefinition 5 (Absolute settlement). For a dynamic ledger $\\mathbf{D} \\stackrel{\\text { def }}{=} \\mathbf{L}^{(0)}, \\mathbf{L}^{(1)}, \\ldots$ we say that a transaction $t x \\in$ $A^{(\\tau)} \\cap \\mathbf{L}^{(t)}($ for $\\tau \\leq t)$ is (absolutely) settled at time $t$ iffor all $\\ell \\geq t$ we have: (i) $\\mathbf{L}^{(t)}\\lceil\\mathrm{tx}\\rceil \\subseteq \\mathbf{L}^{(\\ell)}$, (ii) the linear orders $<_{\\mathbf{L}^{(t)}}$ and $<_{\\mathbf{L}^{(t)}}$ agree on $\\mathbf{L}^{(t)}\\lceil\\mathrm{tx}\\rceil$, and (iii) for any $\\mathrm{tx}^{\\prime} \\in \\mathbf{L}^{(e)}$ such that $\\mathrm{tx}^{\\prime}{<_{\\mathbf{L}}(t)} \\mathrm{tx}$ we have $\\mathrm{tx}^{\\prime} \\in \\mathbf{L}^{(t)}\\lceil\\mathrm{tx}\\rceil$.\n\nNote that for any absolutely settled transaction, its validity is determined and it is guaranteed to remain unchanged in the future.\n\nIt will be useful to also consider a weaker notion of relative settlement of a transaction: Intuitively, tx is relatively settled at time $t$ if we have the guarantee that no (conflicting) transaction $\\mathrm{tx}^{\\prime}$ that is not part of the ledger at time $t$ can possibly eventually precede $t x$ in the ledger ordering.',
'paper-title: Casper the Friendly Finality Gadget\n\n\\documentclass[10pt]{article}\n\\usepackage[utf8]{inputenc}\n\\usepackage[T1]{fontenc}\n\\usepackage{amsmath}\n\\usepackage{amsfonts}\n\\usepackage{amssymb}\n\\usepackage[version=4]{mhchem}\n\\usepackage{stmaryrd}\n\\usepackage{graphicx}\n\\usepackage[export]{adjustbox}\n\\graphicspath{ {./images/} }\n\\usepackage{hyperref}\n\\hypersetup{colorlinks=true, linkcolor=blue, filecolor=magenta, urlcolor=cyan,}\n\\urlstyle{same}\n\n\\title{Casper the Friendly Finality Gadget }\n\n\\author{Vitalik Buterin and Virgil Griffith\\\\\nEthereum Foundation}\n\\date{}\n\n\n%New command to display footnote whose markers will always be hidden\n\\let\\svthefootnote\\thefootnote\n\\newcommand\\blfootnotetext[1]{%\n \\let\\thefootnote\\relax\\footnote{#1}%\n \\addtocounter{footnote}{-1}%\n \\let\\thefootnote\\svthefootnote%\n}\n\n%Overriding the \\footnotetext command to hide the marker if its value is `0`\n\\let\\svfootnotetext\\footnotetext\n\\renewcommand\\footnotetext[2][?]{%\n \\if\\relax#1\\relax%\n \\ifnum\\value{footnote}=0\\blfootnotetext{#2}\\else\\svfootnotetext{#2}\\fi%\n \\else%\n \\if?#1\\ifnum\\value{footnote}=0\\blfootnotetext{#2}\\else\\svfootnotetext{#2}\\fi%\n \\else\\svfootnotetext[#1]{#2}\\fi%\n \\fi\n}\n\n\\begin{document}\n\\maketitle\n\n\n\\begin{abstract}\nWe introduce Casper, a proof of stake-based finality system which overlays an existing proof of work blockchain. Casper is a partial consensus mechanism combining proof of stake algorithm research and Byzantine fault tolerant consensus theory. We introduce our system, prove some desirable features, and show defenses against long range revisions and catastrophic crashes. The Casper overlay provides almost any proof of work chain with additional protections against block reversions.\n\\end{abstract}\n\n\\section*{1. Introduction}\nOver the past few years there has been considerable research into "proof of stake" (PoS) based blockchain consensus algorithms. In a PoS system, a blockchain appends and agrees on new blocks through a process where anyone who holds coins inside of the system can participate, and the influence an agent has is proportional to the number of coins (or "stake") it holds. This is a vastly more efficient alternative to proof of work (PoW) "mining" and enables blockchains to operate without mining\'s high hardware and electricity costs.\\\\[0pt]\nThere are two major schools of thought in PoS design. The first, chain-based proof of stake[1, 2], mimics proof of work mechanics and features a chain of blocks and simulates mining by pseudorandomly assigning the right to create new blocks to stakeholders. This includes Peercoin[3], Blackcoin[4], and Iddo Bentov\'s work[5].\\\\[0pt]\nThe other school, Byzantine fault tolerant (BFT) based proof of stake, is based on a thirty-year-old body of research into BFT consensus algorithms such as PBFT[6]. BFT algorithms typically have proven mathematical properties; for example, one can usually mathematically prove that as long as $>\\frac{2}{3}$ of protocol participants are following the protocol honestly, then, regardless of network latency, the algorithm cannot finalize conflicting blocks. Repurposing BFT algorithms for proof of stake was first introduced by Tendermint[7], and has modern inspirations such as [8]. Casper follows this BFT tradition, though with some modifications.\n\n\\subsection*{1.1. Our Work}\nCasper the Friendly Finality Gadget is an overlay atop a proposal mechanism-a mechanism which proposes blocks ${ }^{1}$. Casper is responsible for finalizing these blocks, essentially selecting a unique chain which represents the canonical transactions of the ledger. Casper provides safety, but liveness depends on the chosen proposal mechanism. That is, if attackers wholly control the proposal mechanism, Casper protects against finalizing two conflicting checkpoints, but the attackers could prevent Casper from finalizing any future checkpoints.\\\\\nCasper introduces several new features that BFT algorithms do not necessarily support:',
]
embeddings = model.encode(sentences)
print(embeddings.shape)
# [3, 768]
# Get the similarity scores for the embeddings
similarities = model.similarity(embeddings, embeddings)
print(similarities.shape)
# [3, 3]
```
<!--
### Direct Usage (Transformers)
<details><summary>Click to see the direct usage in Transformers</summary>
</details>
-->
<!--
### Downstream Usage (Sentence Transformers)
You can finetune this model on your own dataset.
<details><summary>Click to expand</summary>
</details>
-->
<!--
### Out-of-Scope Use
*List how the model may foreseeably be misused and address what users ought not to do with the model.*
-->
## Evaluation
### Metrics
#### Information Retrieval
* Datasets: `dim_768`, `dim_512`, `dim_256`, `dim_128` and `dim_64`
* Evaluated with [<code>InformationRetrievalEvaluator</code>](https://sbert.net/docs/package_reference/sentence_transformer/evaluation.html#sentence_transformers.evaluation.InformationRetrievalEvaluator)
| Metric | dim_768 | dim_512 | dim_256 | dim_128 | dim_64 |
|:--------------------|:-----------|:-----------|:-----------|:-----------|:-----------|
| cosine_accuracy@1 | 0.5 | 0.5714 | 0.5714 | 0.5 | 0.4286 |
| cosine_accuracy@3 | 0.7857 | 0.7857 | 0.7857 | 0.75 | 0.6786 |
| cosine_accuracy@5 | 0.8571 | 0.8214 | 0.8214 | 0.8214 | 0.75 |
| cosine_accuracy@10 | 0.8571 | 0.8571 | 0.8571 | 0.8571 | 0.8214 |
| cosine_precision@1 | 0.5 | 0.5714 | 0.5714 | 0.5 | 0.4286 |
| cosine_precision@3 | 0.2619 | 0.2619 | 0.2619 | 0.25 | 0.2262 |
| cosine_precision@5 | 0.1714 | 0.1643 | 0.1643 | 0.1643 | 0.15 |
| cosine_precision@10 | 0.0857 | 0.0857 | 0.0857 | 0.0857 | 0.0821 |
| cosine_recall@1 | 0.5 | 0.5714 | 0.5714 | 0.5 | 0.4286 |
| cosine_recall@3 | 0.7857 | 0.7857 | 0.7857 | 0.75 | 0.6786 |
| cosine_recall@5 | 0.8571 | 0.8214 | 0.8214 | 0.8214 | 0.75 |
| cosine_recall@10 | 0.8571 | 0.8571 | 0.8571 | 0.8571 | 0.8214 |
| **cosine_ndcg@10** | **0.7032** | **0.7277** | **0.7285** | **0.6935** | **0.6316** |
| cosine_mrr@10 | 0.6512 | 0.6849 | 0.6857 | 0.6396 | 0.5696 |
| cosine_map@100 | 0.6553 | 0.6886 | 0.6893 | 0.6425 | 0.5757 |
<!--
## Bias, Risks and Limitations
*What are the known or foreseeable issues stemming from this model? You could also flag here known failure cases or weaknesses of the model.*
-->
<!--
### Recommendations
*What are recommendations with respect to the foreseeable issues? For example, filtering explicit content.*
-->
## Training Details
### Training Dataset
#### json
* Dataset: json
* Size: 278 training samples
* Columns: <code>anchor</code> and <code>positive</code>
* Approximate statistics based on the first 278 samples:
| | anchor | positive |
|:--------|:-----------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------|
| type | string | string |
| details | <ul><li>min: 14 tokens</li><li>mean: 26.06 tokens</li><li>max: 72 tokens</li></ul> | <ul><li>min: 512 tokens</li><li>mean: 512.0 tokens</li><li>max: 512 tokens</li></ul> |
* Samples:
| anchor | positive |
|:-----------------------------------------------------------------------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| <code>How does ByzCoin ensure that microblock chains remain consistent even in the presence of keyblock conflicts?</code> | <code>paper-title: Enhancing Bitcoin Security and Performance with Strong Consistency via Collective Signing<br><br>Figure 3: ByzCoin blockchain: Two parallel chains store information about the leaders (keyblocks) and the transactions (microblocks)\\<br>becomes two separate parallel blockchains, as shown in Fig. 3. The main blockchain is the keyblock chain, consisting of all mined blocks. The microblock chain is a secondary blockchain that depends on the primary to identify the era in which every microblock belongs to, i.e., which miners are authoritative to sign it and who is the leader of the era.<br><br>Microblocks. A microblock is a simple block that the current consensus group produces every few seconds to represent newly-committed transactions. Each microblock includes a set of transactions and a collective signature. Each microblock also includes hashes referring to the previous microblock and keyblock: the former to ensure total ordering, and the latter indicating which consensus group window and l...</code> |
| <code>What are the primary ways in which Bitcoin users can be deanonymized, and why is network-layer deanonymization particularly concerning?</code> | <code>paper-title: Bitcoin and Cryptocurrency Technologies<br><br>This is is exactly what the Fistful of Bitcoins researchers (and others since) have done. They bought a variety of things, joined mining pools, used Bitcoin exchanges, wallet services, and gambling sites, and interacted in a variety of other ways with service providers, compromising 344 transactions in all.<br><br>In Figure 6.5, we again show the clusters of Figure 6.4, but this times with the labels attached. While our guesses about Mt. gox and Satoshi Dice were correct, the researchers were able to identify numerous other service providers that would have been hard to identify without transacting with them.\\<br>\includegraphics[max width=\textwidth, center]{2025_01_02_05ab7f20e06e1a41e145g-175}<br><br>Figure 6.5. Labeled clusters. By transacting with various Bitcoin service providers, Meiklejohn et al. were able to attach real world identities to their clusters.<br><br>Identifying individuals. The next question is: can we do the same thing for indivi...</code> |
| <code>What is the main purpose of the ledger indistinguishability and transaction non-malleability properties in the Zerocash protocol?</code> | <code>paper-title: Zerocash: Decentralized Anonymous Payments from Bitcoin<br><br>Ledger indistinguishability is formalized by an experiment L-IND that proceeds as follows. First, a challenger samples a random bit $b$ and initializes two DAP scheme oracles $\mathcal{O}_{0}^{\text {DAP }}$ and $\mathcal{O}_{1}^{\text {DAP }}$, maintaining ledgers $L_{0}$ and $L_{1}$. Throughout, the challenger allows $\mathcal{A}$ to issue queries to $\mathcal{O}_{0}^{\text {DAP }}$ and $\mathcal{O}_{1}^{\text {DAP }}$, thus controlling the behavior of honest parties on $L_{0}$ and $L_{1}$. The challenger provides the adversary with the view of both ledgers, but in randomized order: $L_{\text {Left }}:=L_{b}$ and $L_{\text {Right }}:=L_{1-b}$. The adversary's goal is to distinguish whether the view he sees corresponds to $\left(L_{\text {Left }}, L_{\text {Right }}\right)=\left(L_{0}, L_{1}\right)$, i.e. $b=0$, or to $\left(L_{\text {Left }}, L_{\text {Right }}\right)=\left(L_{1}, L_{0}\right)$, i.e. $b=1$.<br><br>At eac...</code> |
* Loss: [<code>MatryoshkaLoss</code>](https://sbert.net/docs/package_reference/sentence_transformer/losses.html#matryoshkaloss) with these parameters:
```json
{
"loss": "MultipleNegativesRankingLoss",
"matryoshka_dims": [
768,
512,
256,
128,
64
],
"matryoshka_weights": [
1,
1,
1,
1,
1
],
"n_dims_per_step": -1
}
```
### Training Hyperparameters
#### Non-Default Hyperparameters
- `eval_strategy`: epoch
- `per_device_train_batch_size`: 32
- `gradient_accumulation_steps`: 16
- `learning_rate`: 2e-05
- `num_train_epochs`: 4
#### All Hyperparameters
<details><summary>Click to expand</summary>
- `overwrite_output_dir`: False
- `do_predict`: False
- `eval_strategy`: epoch
- `prediction_loss_only`: True
- `per_device_train_batch_size`: 32
- `per_device_eval_batch_size`: 8
- `per_gpu_train_batch_size`: None
- `per_gpu_eval_batch_size`: None
- `gradient_accumulation_steps`: 16
- `eval_accumulation_steps`: None
- `learning_rate`: 2e-05
- `weight_decay`: 0.0
- `adam_beta1`: 0.9
- `adam_beta2`: 0.999
- `adam_epsilon`: 1e-08
- `max_grad_norm`: 1.0
- `num_train_epochs`: 4
- `max_steps`: -1
- `lr_scheduler_type`: linear
- `lr_scheduler_kwargs`: {}
- `warmup_ratio`: 0.0
- `warmup_steps`: 0
- `log_level`: passive
- `log_level_replica`: warning
- `log_on_each_node`: True
- `logging_nan_inf_filter`: True
- `save_safetensors`: True
- `save_on_each_node`: False
- `save_only_model`: False
- `restore_callback_states_from_checkpoint`: False
- `no_cuda`: False
- `use_cpu`: False
- `use_mps_device`: False
- `seed`: 42
- `data_seed`: None
- `jit_mode_eval`: False
- `use_ipex`: False
- `bf16`: False
- `fp16`: False
- `fp16_opt_level`: O1
- `half_precision_backend`: auto
- `bf16_full_eval`: False
- `fp16_full_eval`: False
- `tf32`: None
- `local_rank`: 0
- `ddp_backend`: None
- `tpu_num_cores`: None
- `tpu_metrics_debug`: False
- `debug`: []
- `dataloader_drop_last`: False
- `dataloader_num_workers`: 0
- `dataloader_prefetch_factor`: None
- `past_index`: -1
- `disable_tqdm`: False
- `remove_unused_columns`: True
- `label_names`: None
- `load_best_model_at_end`: False
- `ignore_data_skip`: False
- `fsdp`: []
- `fsdp_min_num_params`: 0
- `fsdp_config`: {'min_num_params': 0, 'xla': False, 'xla_fsdp_v2': False, 'xla_fsdp_grad_ckpt': False}
- `fsdp_transformer_layer_cls_to_wrap`: None
- `accelerator_config`: {'split_batches': False, 'dispatch_batches': None, 'even_batches': True, 'use_seedable_sampler': True, 'non_blocking': False, 'gradient_accumulation_kwargs': None}
- `deepspeed`: None
- `label_smoothing_factor`: 0.0
- `optim`: adamw_torch
- `optim_args`: None
- `adafactor`: False
- `group_by_length`: False
- `length_column_name`: length
- `ddp_find_unused_parameters`: None
- `ddp_bucket_cap_mb`: None
- `ddp_broadcast_buffers`: False
- `dataloader_pin_memory`: True
- `dataloader_persistent_workers`: False
- `skip_memory_metrics`: True
- `use_legacy_prediction_loop`: False
- `push_to_hub`: False
- `resume_from_checkpoint`: None
- `hub_model_id`: None
- `hub_strategy`: every_save
- `hub_private_repo`: False
- `hub_always_push`: False
- `gradient_checkpointing`: False
- `gradient_checkpointing_kwargs`: None
- `include_inputs_for_metrics`: False
- `eval_do_concat_batches`: True
- `fp16_backend`: auto
- `push_to_hub_model_id`: None
- `push_to_hub_organization`: None
- `mp_parameters`:
- `auto_find_batch_size`: False
- `full_determinism`: False
- `torchdynamo`: None
- `ray_scope`: last
- `ddp_timeout`: 1800
- `torch_compile`: False
- `torch_compile_backend`: None
- `torch_compile_mode`: None
- `dispatch_batches`: None
- `split_batches`: None
- `include_tokens_per_second`: False
- `include_num_input_tokens_seen`: False
- `neftune_noise_alpha`: None
- `optim_target_modules`: None
- `batch_eval_metrics`: False
- `prompts`: None
- `batch_sampler`: batch_sampler
- `multi_dataset_batch_sampler`: proportional
</details>
### Training Logs
| Epoch | Step | dim_768_cosine_ndcg@10 | dim_512_cosine_ndcg@10 | dim_256_cosine_ndcg@10 | dim_128_cosine_ndcg@10 | dim_64_cosine_ndcg@10 |
|:-----:|:----:|:----------------------:|:----------------------:|:----------------------:|:----------------------:|:---------------------:|
| 1.0 | 1 | 0.6975 | 0.6930 | 0.6760 | 0.6960 | 0.6098 |
| 2.0 | 2 | 0.7258 | 0.7082 | 0.7062 | 0.6935 | 0.6231 |
| 3.0 | 3 | 0.7079 | 0.7270 | 0.7067 | 0.6935 | 0.6184 |
| 4.0 | 4 | 0.7032 | 0.7277 | 0.7285 | 0.6935 | 0.6316 |
### Framework Versions
- Python: 3.10.16
- Sentence Transformers: 3.3.1
- Transformers: 4.41.2
- PyTorch: 2.5.1+cu118
- Accelerate: 1.2.1
- Datasets: 2.19.1
- Tokenizers: 0.19.1
## Citation
### BibTeX
#### Sentence Transformers
```bibtex
@inproceedings{reimers-2019-sentence-bert,
title = "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks",
author = "Reimers, Nils and Gurevych, Iryna",
booktitle = "Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing",
month = "11",
year = "2019",
publisher = "Association for Computational Linguistics",
url = "https://arxiv.org/abs/1908.10084",
}
```
#### MatryoshkaLoss
```bibtex
@misc{kusupati2024matryoshka,
title={Matryoshka Representation Learning},
author={Aditya Kusupati and Gantavya Bhatt and Aniket Rege and Matthew Wallingford and Aditya Sinha and Vivek Ramanujan and William Howard-Snyder and Kaifeng Chen and Sham Kakade and Prateek Jain and Ali Farhadi},
year={2024},
eprint={2205.13147},
archivePrefix={arXiv},
primaryClass={cs.LG}
}
```
#### MultipleNegativesRankingLoss
```bibtex
@misc{henderson2017efficient,
title={Efficient Natural Language Response Suggestion for Smart Reply},
author={Matthew Henderson and Rami Al-Rfou and Brian Strope and Yun-hsuan Sung and Laszlo Lukacs and Ruiqi Guo and Sanjiv Kumar and Balint Miklos and Ray Kurzweil},
year={2017},
eprint={1705.00652},
archivePrefix={arXiv},
primaryClass={cs.CL}
}
```
<!--
## Glossary
*Clearly define terms in order to be accessible across audiences.*
-->
<!--
## Model Card Authors
*Lists the people who create the model card, providing recognition and accountability for the detailed work that goes into its construction.*
-->
<!--
## Model Card Contact
*Provides a way for people who have updates to the Model Card, suggestions, or questions, to contact the Model Card authors.*
--> |