├── IEEEtran.bst ├── Makefile ├── README.md ├── appendix.tex ├── cbc-casper-paper-draft.pdf ├── cbc-casper-paper-draft.tex ├── conclusion.tex ├── ethereum.bib └── examples.tex /IEEEtran.bst: -------------------------------------------------------------------------------- 1 | %% 2 | %% IEEEtran.bst 3 | %% BibTeX Bibliography Style file for IEEE Journals and Conferences (unsorted) 4 | %% Version 1.14 (2015/08/26) 5 | %% 6 | %% Copyright (c) 2003-2015 Michael Shell 7 | %% 8 | %% Original starting code base and algorithms obtained from the output of 9 | %% Patrick W. Daly's makebst package as well as from prior versions of 10 | %% IEEE BibTeX styles: 11 | %% 12 | %% 1. Howard Trickey and Oren Patashnik's ieeetr.bst (1985/1988) 13 | %% 2. Silvano Balemi and Richard H. Roy's IEEEbib.bst (1993) 14 | %% 15 | %% Support sites: 16 | %% http://www.michaelshell.org/tex/ieeetran/ 17 | %% http://www.ctan.org/pkg/ieeetran 18 | %% and/or 19 | %% http://www.ieee.org/ 20 | %% 21 | %% For use with BibTeX version 0.99a or later 22 | %% 23 | %% This is a numerical citation style. 24 | %% 25 | %%************************************************************************* 26 | %% Legal Notice: 27 | %% This code is offered as-is without any warranty either expressed or 28 | %% implied; without even the implied warranty of MERCHANTABILITY or 29 | %% FITNESS FOR A PARTICULAR PURPOSE! 30 | %% User assumes all risk. 31 | %% In no event shall the IEEE or any contributor to this code be liable for 32 | %% any damages or losses, including, but not limited to, incidental, 33 | %% consequential, or any other damages, resulting from the use or misuse 34 | %% of any information contained here. 35 | %% 36 | %% All comments are the opinions of their respective authors and are not 37 | %% necessarily endorsed by the IEEE. 38 | %% 39 | %% This work is distributed under the LaTeX Project Public License (LPPL) 40 | %% ( http://www.latex-project.org/ ) version 1.3, and may be freely used, 41 | %% distributed and modified. A copy of the LPPL, version 1.3, is included 42 | %% in the base LaTeX documentation of all distributions of LaTeX released 43 | %% 2003/12/01 or later. 44 | %% Retain all contribution notices and credits. 45 | %% ** Modified files should be clearly indicated as such, including ** 46 | %% ** renaming them and changing author support contact information. ** 47 | %%************************************************************************* 48 | 49 | 50 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 51 | %% DEFAULTS FOR THE CONTROLS OF THE BST STYLE %% 52 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 53 | 54 | % These are the defaults for the user adjustable controls. The values used 55 | % here can be overridden by the user via IEEEtranBSTCTL entry type. 56 | 57 | % NOTE: The recommended LaTeX command to invoke a control entry type is: 58 | % 59 | %\makeatletter 60 | %\def\bstctlcite{\@ifnextchar[{\@bstctlcite}{\@bstctlcite[@auxout]}} 61 | %\def\@bstctlcite[#1]#2{\@bsphack 62 | % \@for\@citeb:=#2\do{% 63 | % \edef\@citeb{\expandafter\@firstofone\@citeb}% 64 | % \if@filesw\immediate\write\csname #1\endcsname{\string\citation{\@citeb}}\fi}% 65 | % \@esphack} 66 | %\makeatother 67 | % 68 | % It is called at the start of the document, before the first \cite, like: 69 | % \bstctlcite{IEEEexample:BSTcontrol} 70 | % 71 | % IEEEtran.cls V1.6 and later does provide this command. 72 | 73 | 74 | 75 | % #0 turns off the display of the number for articles. 76 | % #1 enables 77 | FUNCTION {default.is.use.number.for.article} { #1 } 78 | 79 | 80 | % #0 turns off the display of the paper and type fields in @inproceedings. 81 | % #1 enables 82 | FUNCTION {default.is.use.paper} { #1 } 83 | 84 | 85 | % #0 turns off the display of urls 86 | % #1 enables 87 | FUNCTION {default.is.use.url} { #1 } 88 | 89 | 90 | % #0 turns off the forced use of "et al." 91 | % #1 enables 92 | FUNCTION {default.is.forced.et.al} { #0 } 93 | 94 | 95 | % The maximum number of names that can be present beyond which an "et al." 96 | % usage is forced. Be sure that num.names.shown.with.forced.et.al (below) 97 | % is not greater than this value! 98 | % Note: There are many instances of references in IEEE journals which have 99 | % a very large number of authors as well as instances in which "et al." is 100 | % used profusely. 101 | FUNCTION {default.max.num.names.before.forced.et.al} { #10 } 102 | 103 | 104 | % The number of names that will be shown with a forced "et al.". 105 | % Must be less than or equal to max.num.names.before.forced.et.al 106 | FUNCTION {default.num.names.shown.with.forced.et.al} { #1 } 107 | 108 | 109 | % #0 turns off the alternate interword spacing for entries with URLs. 110 | % #1 enables 111 | FUNCTION {default.is.use.alt.interword.spacing} { #1 } 112 | 113 | 114 | % If alternate interword spacing for entries with URLs is enabled, this is 115 | % the interword spacing stretch factor that will be used. For example, the 116 | % default "4" here means that the interword spacing in entries with URLs can 117 | % stretch to four times normal. Does not have to be an integer. Note that 118 | % the value specified here can be overridden by the user in their LaTeX 119 | % code via a command such as: 120 | % "\providecommand\BIBentryALTinterwordstretchfactor{1.5}" in addition to 121 | % that via the IEEEtranBSTCTL entry type. 122 | FUNCTION {default.ALTinterwordstretchfactor} { "4" } 123 | 124 | 125 | % #0 turns off the "dashification" of repeated (i.e., identical to those 126 | % of the previous entry) names. The IEEE normally does this. 127 | % #1 enables 128 | FUNCTION {default.is.dash.repeated.names} { #1 } 129 | 130 | 131 | % The default name format control string. 132 | FUNCTION {default.name.format.string}{ "{f.~}{vv~}{ll}{, jj}" } 133 | 134 | 135 | % The default LaTeX font command for the names. 136 | FUNCTION {default.name.latex.cmd}{ "" } 137 | 138 | 139 | % The default URL prefix. 140 | FUNCTION {default.name.url.prefix}{ "[Online]. Available:" } 141 | 142 | 143 | % Other controls that cannot be accessed via IEEEtranBSTCTL entry type. 144 | 145 | % #0 turns off the terminal startup banner/completed message so as to 146 | % operate more quietly. 147 | % #1 enables 148 | FUNCTION {is.print.banners.to.terminal} { #1 } 149 | 150 | 151 | 152 | 153 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%% 154 | %% FILE VERSION AND BANNER %% 155 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%% 156 | 157 | FUNCTION{bst.file.version} { "1.14" } 158 | FUNCTION{bst.file.date} { "2015/08/26" } 159 | FUNCTION{bst.file.website} { "http://www.michaelshell.org/tex/ieeetran/bibtex/" } 160 | 161 | FUNCTION {banner.message} 162 | { is.print.banners.to.terminal 163 | { "-- IEEEtran.bst version" " " * bst.file.version * 164 | " (" * bst.file.date * ") " * "by Michael Shell." * 165 | top$ 166 | "-- " bst.file.website * 167 | top$ 168 | "-- See the " quote$ * "IEEEtran_bst_HOWTO.pdf" * quote$ * " manual for usage information." * 169 | top$ 170 | } 171 | { skip$ } 172 | if$ 173 | } 174 | 175 | FUNCTION {completed.message} 176 | { is.print.banners.to.terminal 177 | { "" 178 | top$ 179 | "Done." 180 | top$ 181 | } 182 | { skip$ } 183 | if$ 184 | } 185 | 186 | 187 | 188 | 189 | %%%%%%%%%%%%%%%%%%%%%% 190 | %% STRING CONSTANTS %% 191 | %%%%%%%%%%%%%%%%%%%%%% 192 | 193 | FUNCTION {bbl.and}{ "and" } 194 | FUNCTION {bbl.etal}{ "et~al." } 195 | FUNCTION {bbl.editors}{ "eds." } 196 | FUNCTION {bbl.editor}{ "ed." } 197 | FUNCTION {bbl.edition}{ "ed." } 198 | FUNCTION {bbl.volume}{ "vol." } 199 | FUNCTION {bbl.of}{ "of" } 200 | FUNCTION {bbl.number}{ "no." } 201 | FUNCTION {bbl.in}{ "in" } 202 | FUNCTION {bbl.pages}{ "pp." } 203 | FUNCTION {bbl.page}{ "p." } 204 | FUNCTION {bbl.chapter}{ "ch." } 205 | FUNCTION {bbl.paper}{ "paper" } 206 | FUNCTION {bbl.part}{ "pt." } 207 | FUNCTION {bbl.patent}{ "Patent" } 208 | FUNCTION {bbl.patentUS}{ "U.S." } 209 | FUNCTION {bbl.revision}{ "Rev." } 210 | FUNCTION {bbl.series}{ "ser." } 211 | FUNCTION {bbl.standard}{ "Std." } 212 | FUNCTION {bbl.techrep}{ "Tech. Rep." } 213 | FUNCTION {bbl.mthesis}{ "Master's thesis" } 214 | FUNCTION {bbl.phdthesis}{ "Ph.D. dissertation" } 215 | FUNCTION {bbl.st}{ "st" } 216 | FUNCTION {bbl.nd}{ "nd" } 217 | FUNCTION {bbl.rd}{ "rd" } 218 | FUNCTION {bbl.th}{ "th" } 219 | 220 | 221 | % This is the LaTeX spacer that is used when a larger than normal space 222 | % is called for (such as just before the address:publisher). 223 | FUNCTION {large.space} { "\hskip 1em plus 0.5em minus 0.4em\relax " } 224 | 225 | % The LaTeX code for dashes that are used to represent repeated names. 226 | % Note: Some older IEEE journals used something like 227 | % "\rule{0.275in}{0.5pt}\," which is fairly thick and runs right along 228 | % the baseline. However, the IEEE now uses a thinner, above baseline, 229 | % six dash long sequence. 230 | FUNCTION {repeated.name.dashes} { "------" } 231 | 232 | 233 | 234 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 235 | %% PREDEFINED STRING MACROS %% 236 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 237 | 238 | MACRO {jan} {"Jan."} 239 | MACRO {feb} {"Feb."} 240 | MACRO {mar} {"Mar."} 241 | MACRO {apr} {"Apr."} 242 | MACRO {may} {"May"} 243 | MACRO {jun} {"Jun."} 244 | MACRO {jul} {"Jul."} 245 | MACRO {aug} {"Aug."} 246 | MACRO {sep} {"Sep."} 247 | MACRO {oct} {"Oct."} 248 | MACRO {nov} {"Nov."} 249 | MACRO {dec} {"Dec."} 250 | 251 | 252 | 253 | %%%%%%%%%%%%%%%%%% 254 | %% ENTRY FIELDS %% 255 | %%%%%%%%%%%%%%%%%% 256 | 257 | ENTRY 258 | { address 259 | assignee 260 | author 261 | booktitle 262 | chapter 263 | day 264 | dayfiled 265 | edition 266 | editor 267 | howpublished 268 | institution 269 | intype 270 | journal 271 | key 272 | language 273 | month 274 | monthfiled 275 | nationality 276 | note 277 | number 278 | organization 279 | pages 280 | paper 281 | publisher 282 | school 283 | series 284 | revision 285 | title 286 | type 287 | url 288 | volume 289 | year 290 | yearfiled 291 | CTLuse_article_number 292 | CTLuse_paper 293 | CTLuse_url 294 | CTLuse_forced_etal 295 | CTLmax_names_forced_etal 296 | CTLnames_show_etal 297 | CTLuse_alt_spacing 298 | CTLalt_stretch_factor 299 | CTLdash_repeated_names 300 | CTLname_format_string 301 | CTLname_latex_cmd 302 | CTLname_url_prefix 303 | } 304 | {} 305 | { label } 306 | 307 | 308 | 309 | 310 | %%%%%%%%%%%%%%%%%%%%%%% 311 | %% INTEGER VARIABLES %% 312 | %%%%%%%%%%%%%%%%%%%%%%% 313 | 314 | INTEGERS { prev.status.punct this.status.punct punct.std 315 | punct.no punct.comma punct.period 316 | prev.status.space this.status.space space.std 317 | space.no space.normal space.large 318 | prev.status.quote this.status.quote quote.std 319 | quote.no quote.close 320 | prev.status.nline this.status.nline nline.std 321 | nline.no nline.newblock 322 | status.cap cap.std 323 | cap.no cap.yes} 324 | 325 | INTEGERS { longest.label.width multiresult nameptr namesleft number.label numnames } 326 | 327 | INTEGERS { is.use.number.for.article 328 | is.use.paper 329 | is.use.url 330 | is.forced.et.al 331 | max.num.names.before.forced.et.al 332 | num.names.shown.with.forced.et.al 333 | is.use.alt.interword.spacing 334 | is.dash.repeated.names} 335 | 336 | 337 | %%%%%%%%%%%%%%%%%%%%%% 338 | %% STRING VARIABLES %% 339 | %%%%%%%%%%%%%%%%%%%%%% 340 | 341 | STRINGS { bibinfo 342 | longest.label 343 | oldname 344 | s 345 | t 346 | ALTinterwordstretchfactor 347 | name.format.string 348 | name.latex.cmd 349 | name.url.prefix} 350 | 351 | 352 | 353 | 354 | %%%%%%%%%%%%%%%%%%%%%%%%% 355 | %% LOW LEVEL FUNCTIONS %% 356 | %%%%%%%%%%%%%%%%%%%%%%%%% 357 | 358 | FUNCTION {initialize.controls} 359 | { default.is.use.number.for.article 'is.use.number.for.article := 360 | default.is.use.paper 'is.use.paper := 361 | default.is.use.url 'is.use.url := 362 | default.is.forced.et.al 'is.forced.et.al := 363 | default.max.num.names.before.forced.et.al 'max.num.names.before.forced.et.al := 364 | default.num.names.shown.with.forced.et.al 'num.names.shown.with.forced.et.al := 365 | default.is.use.alt.interword.spacing 'is.use.alt.interword.spacing := 366 | default.is.dash.repeated.names 'is.dash.repeated.names := 367 | default.ALTinterwordstretchfactor 'ALTinterwordstretchfactor := 368 | default.name.format.string 'name.format.string := 369 | default.name.latex.cmd 'name.latex.cmd := 370 | default.name.url.prefix 'name.url.prefix := 371 | } 372 | 373 | 374 | % This IEEEtran.bst features a very powerful and flexible mechanism for 375 | % controlling the capitalization, punctuation, spacing, quotation, and 376 | % newlines of the formatted entry fields. (Note: IEEEtran.bst does not need 377 | % or use the newline/newblock feature, but it has been implemented for 378 | % possible future use.) The output states of IEEEtran.bst consist of 379 | % multiple independent attributes and, as such, can be thought of as being 380 | % vectors, rather than the simple scalar values ("before.all", 381 | % "mid.sentence", etc.) used in most other .bst files. 382 | % 383 | % The more flexible and complex design used here was motivated in part by 384 | % the IEEE's rather unusual bibliography style. For example, the IEEE ends the 385 | % previous field item with a period and large space prior to the publisher 386 | % address; the @electronic entry types use periods as inter-item punctuation 387 | % rather than the commas used by the other entry types; and URLs are never 388 | % followed by periods even though they are the last item in the entry. 389 | % Although it is possible to accommodate these features with the conventional 390 | % output state system, the seemingly endless exceptions make for convoluted, 391 | % unreliable and difficult to maintain code. 392 | % 393 | % IEEEtran.bst's output state system can be easily understood via a simple 394 | % illustration of two most recently formatted entry fields (on the stack): 395 | % 396 | % CURRENT_ITEM 397 | % "PREVIOUS_ITEM 398 | % 399 | % which, in this example, is to eventually appear in the bibliography as: 400 | % 401 | % "PREVIOUS_ITEM," CURRENT_ITEM 402 | % 403 | % It is the job of the output routine to take the previous item off of the 404 | % stack (while leaving the current item at the top of the stack), apply its 405 | % trailing punctuation (including closing quote marks) and spacing, and then 406 | % to write the result to BibTeX's output buffer: 407 | % 408 | % "PREVIOUS_ITEM," 409 | % 410 | % Punctuation (and spacing) between items is often determined by both of the 411 | % items rather than just the first one. The presence of quotation marks 412 | % further complicates the situation because, in standard English, trailing 413 | % punctuation marks are supposed to be contained within the quotes. 414 | % 415 | % IEEEtran.bst maintains two output state (aka "status") vectors which 416 | % correspond to the previous and current (aka "this") items. Each vector 417 | % consists of several independent attributes which track punctuation, 418 | % spacing, quotation, and newlines. Capitalization status is handled by a 419 | % separate scalar because the format routines, not the output routine, 420 | % handle capitalization and, therefore, there is no need to maintain the 421 | % capitalization attribute for both the "previous" and "this" items. 422 | % 423 | % When a format routine adds a new item, it copies the current output status 424 | % vector to the previous output status vector and (usually) resets the 425 | % current (this) output status vector to a "standard status" vector. Using a 426 | % "standard status" vector in this way allows us to redefine what we mean by 427 | % "standard status" at the start of each entry handler and reuse the same 428 | % format routines under the various inter-item separation schemes. For 429 | % example, the standard status vector for the @book entry type may use 430 | % commas for item separators, while the @electronic type may use periods, 431 | % yet both entry handlers exploit many of the exact same format routines. 432 | % 433 | % Because format routines have write access to the output status vector of 434 | % the previous item, they can override the punctuation choices of the 435 | % previous format routine! Therefore, it becomes trivial to implement rules 436 | % such as "Always use a period and a large space before the publisher." By 437 | % pushing the generation of the closing quote mark to the output routine, we 438 | % avoid all the problems caused by having to close a quote before having all 439 | % the information required to determine what the punctuation should be. 440 | % 441 | % The IEEEtran.bst output state system can easily be expanded if needed. 442 | % For instance, it is easy to add a "space.tie" attribute value if the 443 | % bibliography rules mandate that two items have to be joined with an 444 | % unbreakable space. 445 | 446 | FUNCTION {initialize.status.constants} 447 | { #0 'punct.no := 448 | #1 'punct.comma := 449 | #2 'punct.period := 450 | #0 'space.no := 451 | #1 'space.normal := 452 | #2 'space.large := 453 | #0 'quote.no := 454 | #1 'quote.close := 455 | #0 'cap.no := 456 | #1 'cap.yes := 457 | #0 'nline.no := 458 | #1 'nline.newblock := 459 | } 460 | 461 | FUNCTION {std.status.using.comma} 462 | { punct.comma 'punct.std := 463 | space.normal 'space.std := 464 | quote.no 'quote.std := 465 | nline.no 'nline.std := 466 | cap.no 'cap.std := 467 | } 468 | 469 | FUNCTION {std.status.using.period} 470 | { punct.period 'punct.std := 471 | space.normal 'space.std := 472 | quote.no 'quote.std := 473 | nline.no 'nline.std := 474 | cap.yes 'cap.std := 475 | } 476 | 477 | FUNCTION {initialize.prev.this.status} 478 | { punct.no 'prev.status.punct := 479 | space.no 'prev.status.space := 480 | quote.no 'prev.status.quote := 481 | nline.no 'prev.status.nline := 482 | punct.no 'this.status.punct := 483 | space.no 'this.status.space := 484 | quote.no 'this.status.quote := 485 | nline.no 'this.status.nline := 486 | cap.yes 'status.cap := 487 | } 488 | 489 | FUNCTION {this.status.std} 490 | { punct.std 'this.status.punct := 491 | space.std 'this.status.space := 492 | quote.std 'this.status.quote := 493 | nline.std 'this.status.nline := 494 | } 495 | 496 | FUNCTION {cap.status.std}{ cap.std 'status.cap := } 497 | 498 | FUNCTION {this.to.prev.status} 499 | { this.status.punct 'prev.status.punct := 500 | this.status.space 'prev.status.space := 501 | this.status.quote 'prev.status.quote := 502 | this.status.nline 'prev.status.nline := 503 | } 504 | 505 | 506 | FUNCTION {not} 507 | { { #0 } 508 | { #1 } 509 | if$ 510 | } 511 | 512 | FUNCTION {and} 513 | { { skip$ } 514 | { pop$ #0 } 515 | if$ 516 | } 517 | 518 | FUNCTION {or} 519 | { { pop$ #1 } 520 | { skip$ } 521 | if$ 522 | } 523 | 524 | 525 | % convert the strings "yes" or "no" to #1 or #0 respectively 526 | FUNCTION {yes.no.to.int} 527 | { "l" change.case$ duplicate$ 528 | "yes" = 529 | { pop$ #1 } 530 | { duplicate$ "no" = 531 | { pop$ #0 } 532 | { "unknown boolean " quote$ * swap$ * quote$ * 533 | " in " * cite$ * warning$ 534 | #0 535 | } 536 | if$ 537 | } 538 | if$ 539 | } 540 | 541 | 542 | % pushes true if the single char string on the stack is in the 543 | % range of "0" to "9" 544 | FUNCTION {is.num} 545 | { chr.to.int$ 546 | duplicate$ "0" chr.to.int$ < not 547 | swap$ "9" chr.to.int$ > not and 548 | } 549 | 550 | % multiplies the integer on the stack by a factor of 10 551 | FUNCTION {bump.int.mag} 552 | { #0 'multiresult := 553 | { duplicate$ #0 > } 554 | { #1 - 555 | multiresult #10 + 556 | 'multiresult := 557 | } 558 | while$ 559 | pop$ 560 | multiresult 561 | } 562 | 563 | % converts a single character string on the stack to an integer 564 | FUNCTION {char.to.integer} 565 | { duplicate$ 566 | is.num 567 | { chr.to.int$ "0" chr.to.int$ - } 568 | {"noninteger character " quote$ * swap$ * quote$ * 569 | " in integer field of " * cite$ * warning$ 570 | #0 571 | } 572 | if$ 573 | } 574 | 575 | % converts a string on the stack to an integer 576 | FUNCTION {string.to.integer} 577 | { duplicate$ text.length$ 'namesleft := 578 | #1 'nameptr := 579 | #0 'numnames := 580 | { nameptr namesleft > not } 581 | { duplicate$ nameptr #1 substring$ 582 | char.to.integer numnames bump.int.mag + 583 | 'numnames := 584 | nameptr #1 + 585 | 'nameptr := 586 | } 587 | while$ 588 | pop$ 589 | numnames 590 | } 591 | 592 | 593 | 594 | 595 | % The output routines write out the *next* to the top (previous) item on the 596 | % stack, adding punctuation and such as needed. Since IEEEtran.bst maintains 597 | % the output status for the top two items on the stack, these output 598 | % routines have to consider the previous output status (which corresponds to 599 | % the item that is being output). Full independent control of punctuation, 600 | % closing quote marks, spacing, and newblock is provided. 601 | % 602 | % "output.nonnull" does not check for the presence of a previous empty 603 | % item. 604 | % 605 | % "output" does check for the presence of a previous empty item and will 606 | % remove an empty item rather than outputing it. 607 | % 608 | % "output.warn" is like "output", but will issue a warning if it detects 609 | % an empty item. 610 | 611 | FUNCTION {output.nonnull} 612 | { swap$ 613 | prev.status.punct punct.comma = 614 | { "," * } 615 | { skip$ } 616 | if$ 617 | prev.status.punct punct.period = 618 | { add.period$ } 619 | { skip$ } 620 | if$ 621 | prev.status.quote quote.close = 622 | { "''" * } 623 | { skip$ } 624 | if$ 625 | prev.status.space space.normal = 626 | { " " * } 627 | { skip$ } 628 | if$ 629 | prev.status.space space.large = 630 | { large.space * } 631 | { skip$ } 632 | if$ 633 | write$ 634 | prev.status.nline nline.newblock = 635 | { newline$ "\newblock " write$ } 636 | { skip$ } 637 | if$ 638 | } 639 | 640 | FUNCTION {output} 641 | { duplicate$ empty$ 642 | 'pop$ 643 | 'output.nonnull 644 | if$ 645 | } 646 | 647 | FUNCTION {output.warn} 648 | { 't := 649 | duplicate$ empty$ 650 | { pop$ "empty " t * " in " * cite$ * warning$ } 651 | 'output.nonnull 652 | if$ 653 | } 654 | 655 | % "fin.entry" is the output routine that handles the last item of the entry 656 | % (which will be on the top of the stack when "fin.entry" is called). 657 | 658 | FUNCTION {fin.entry} 659 | { this.status.punct punct.no = 660 | { skip$ } 661 | { add.period$ } 662 | if$ 663 | this.status.quote quote.close = 664 | { "''" * } 665 | { skip$ } 666 | if$ 667 | write$ 668 | newline$ 669 | } 670 | 671 | 672 | FUNCTION {is.last.char.not.punct} 673 | { duplicate$ 674 | "}" * add.period$ 675 | #-1 #1 substring$ "." = 676 | } 677 | 678 | FUNCTION {is.multiple.pages} 679 | { 't := 680 | #0 'multiresult := 681 | { multiresult not 682 | t empty$ not 683 | and 684 | } 685 | { t #1 #1 substring$ 686 | duplicate$ "-" = 687 | swap$ duplicate$ "," = 688 | swap$ "+" = 689 | or or 690 | { #1 'multiresult := } 691 | { t #2 global.max$ substring$ 't := } 692 | if$ 693 | } 694 | while$ 695 | multiresult 696 | } 697 | 698 | FUNCTION {capitalize}{ "u" change.case$ "t" change.case$ } 699 | 700 | FUNCTION {emphasize} 701 | { duplicate$ empty$ 702 | { pop$ "" } 703 | { "\emph{" swap$ * "}" * } 704 | if$ 705 | } 706 | 707 | FUNCTION {do.name.latex.cmd} 708 | { name.latex.cmd 709 | empty$ 710 | { skip$ } 711 | { name.latex.cmd "{" * swap$ * "}" * } 712 | if$ 713 | } 714 | 715 | % IEEEtran.bst uses its own \BIBforeignlanguage command which directly 716 | % invokes the TeX hyphenation patterns without the need of the Babel 717 | % package. Babel does a lot more than switch hyphenation patterns and 718 | % its loading can cause unintended effects in many class files (such as 719 | % IEEEtran.cls). 720 | FUNCTION {select.language} 721 | { duplicate$ empty$ 'pop$ 722 | { language empty$ 'skip$ 723 | { "\BIBforeignlanguage{" language * "}{" * swap$ * "}" * } 724 | if$ 725 | } 726 | if$ 727 | } 728 | 729 | FUNCTION {tie.or.space.prefix} 730 | { duplicate$ text.length$ #3 < 731 | { "~" } 732 | { " " } 733 | if$ 734 | swap$ 735 | } 736 | 737 | FUNCTION {get.bbl.editor} 738 | { editor num.names$ #1 > 'bbl.editors 'bbl.editor if$ } 739 | 740 | FUNCTION {space.word}{ " " swap$ * " " * } 741 | 742 | 743 | % Field Conditioners, Converters, Checkers and External Interfaces 744 | 745 | FUNCTION {empty.field.to.null.string} 746 | { duplicate$ empty$ 747 | { pop$ "" } 748 | { skip$ } 749 | if$ 750 | } 751 | 752 | FUNCTION {either.or.check} 753 | { empty$ 754 | { pop$ } 755 | { "can't use both " swap$ * " fields in " * cite$ * warning$ } 756 | if$ 757 | } 758 | 759 | FUNCTION {empty.entry.warn} 760 | { author empty$ title empty$ howpublished empty$ 761 | month empty$ year empty$ note empty$ url empty$ 762 | and and and and and and 763 | { "all relevant fields are empty in " cite$ * warning$ } 764 | 'skip$ 765 | if$ 766 | } 767 | 768 | 769 | % The bibinfo system provides a way for the electronic parsing/acquisition 770 | % of a bibliography's contents as is done by ReVTeX. For example, a field 771 | % could be entered into the bibliography as: 772 | % \bibinfo{volume}{2} 773 | % Only the "2" would show up in the document, but the LaTeX \bibinfo command 774 | % could do additional things with the information. IEEEtran.bst does provide 775 | % a \bibinfo command via "\providecommand{\bibinfo}[2]{#2}". However, it is 776 | % currently not used as the bogus bibinfo functions defined here output the 777 | % entry values directly without the \bibinfo wrapper. The bibinfo functions 778 | % themselves (and the calls to them) are retained for possible future use. 779 | % 780 | % bibinfo.check avoids acting on missing fields while bibinfo.warn will 781 | % issue a warning message if a missing field is detected. Prior to calling 782 | % the bibinfo functions, the user should push the field value and then its 783 | % name string, in that order. 784 | 785 | FUNCTION {bibinfo.check} 786 | { swap$ duplicate$ missing$ 787 | { pop$ pop$ "" } 788 | { duplicate$ empty$ 789 | { swap$ pop$ } 790 | { swap$ pop$ } 791 | if$ 792 | } 793 | if$ 794 | } 795 | 796 | FUNCTION {bibinfo.warn} 797 | { swap$ duplicate$ missing$ 798 | { swap$ "missing " swap$ * " in " * cite$ * warning$ pop$ "" } 799 | { duplicate$ empty$ 800 | { swap$ "empty " swap$ * " in " * cite$ * warning$ } 801 | { swap$ pop$ } 802 | if$ 803 | } 804 | if$ 805 | } 806 | 807 | 808 | % The IEEE separates large numbers with more than 4 digits into groups of 809 | % three. The IEEE uses a small space to separate these number groups. 810 | % Typical applications include patent and page numbers. 811 | 812 | % number of consecutive digits required to trigger the group separation. 813 | FUNCTION {large.number.trigger}{ #5 } 814 | 815 | % For numbers longer than the trigger, this is the blocksize of the groups. 816 | % The blocksize must be less than the trigger threshold, and 2 * blocksize 817 | % must be greater than the trigger threshold (can't do more than one 818 | % separation on the initial trigger). 819 | FUNCTION {large.number.blocksize}{ #3 } 820 | 821 | % What is actually inserted between the number groups. 822 | FUNCTION {large.number.separator}{ "\," } 823 | 824 | % So as to save on integer variables by reusing existing ones, numnames 825 | % holds the current number of consecutive digits read and nameptr holds 826 | % the number that will trigger an inserted space. 827 | FUNCTION {large.number.separate} 828 | { 't := 829 | "" 830 | #0 'numnames := 831 | large.number.trigger 'nameptr := 832 | { t empty$ not } 833 | { t #-1 #1 substring$ is.num 834 | { numnames #1 + 'numnames := } 835 | { #0 'numnames := 836 | large.number.trigger 'nameptr := 837 | } 838 | if$ 839 | t #-1 #1 substring$ swap$ * 840 | t #-2 global.max$ substring$ 't := 841 | numnames nameptr = 842 | { duplicate$ #1 nameptr large.number.blocksize - substring$ swap$ 843 | nameptr large.number.blocksize - #1 + global.max$ substring$ 844 | large.number.separator swap$ * * 845 | nameptr large.number.blocksize - 'numnames := 846 | large.number.blocksize #1 + 'nameptr := 847 | } 848 | { skip$ } 849 | if$ 850 | } 851 | while$ 852 | } 853 | 854 | % Converts all single dashes "-" to double dashes "--". 855 | FUNCTION {n.dashify} 856 | { large.number.separate 857 | 't := 858 | "" 859 | { t empty$ not } 860 | { t #1 #1 substring$ "-" = 861 | { t #1 #2 substring$ "--" = not 862 | { "--" * 863 | t #2 global.max$ substring$ 't := 864 | } 865 | { { t #1 #1 substring$ "-" = } 866 | { "-" * 867 | t #2 global.max$ substring$ 't := 868 | } 869 | while$ 870 | } 871 | if$ 872 | } 873 | { t #1 #1 substring$ * 874 | t #2 global.max$ substring$ 't := 875 | } 876 | if$ 877 | } 878 | while$ 879 | } 880 | 881 | 882 | % This function detects entries with names that are identical to that of 883 | % the previous entry and replaces the repeated names with dashes (if the 884 | % "is.dash.repeated.names" user control is nonzero). 885 | FUNCTION {name.or.dash} 886 | { 's := 887 | oldname empty$ 888 | { s 'oldname := s } 889 | { s oldname = 890 | { is.dash.repeated.names 891 | { repeated.name.dashes } 892 | { s 'oldname := s } 893 | if$ 894 | } 895 | { s 'oldname := s } 896 | if$ 897 | } 898 | if$ 899 | } 900 | 901 | % Converts the number string on the top of the stack to 902 | % "numerical ordinal form" (e.g., "7" to "7th"). There is 903 | % no artificial limit to the upper bound of the numbers as the 904 | % two least significant digits determine the ordinal form. 905 | FUNCTION {num.to.ordinal} 906 | { duplicate$ #-2 #1 substring$ "1" = 907 | { bbl.th * } 908 | { duplicate$ #-1 #1 substring$ "1" = 909 | { bbl.st * } 910 | { duplicate$ #-1 #1 substring$ "2" = 911 | { bbl.nd * } 912 | { duplicate$ #-1 #1 substring$ "3" = 913 | { bbl.rd * } 914 | { bbl.th * } 915 | if$ 916 | } 917 | if$ 918 | } 919 | if$ 920 | } 921 | if$ 922 | } 923 | 924 | % If the string on the top of the stack begins with a number, 925 | % (e.g., 11th) then replace the string with the leading number 926 | % it contains. Otherwise retain the string as-is. s holds the 927 | % extracted number, t holds the part of the string that remains 928 | % to be scanned. 929 | FUNCTION {extract.num} 930 | { duplicate$ 't := 931 | "" 's := 932 | { t empty$ not } 933 | { t #1 #1 substring$ 934 | t #2 global.max$ substring$ 't := 935 | duplicate$ is.num 936 | { s swap$ * 's := } 937 | { pop$ "" 't := } 938 | if$ 939 | } 940 | while$ 941 | s empty$ 942 | 'skip$ 943 | { pop$ s } 944 | if$ 945 | } 946 | 947 | % Converts the word number string on the top of the stack to 948 | % Arabic string form. Will be successful up to "tenth". 949 | FUNCTION {word.to.num} 950 | { duplicate$ "l" change.case$ 's := 951 | s "first" = 952 | { pop$ "1" } 953 | { skip$ } 954 | if$ 955 | s "second" = 956 | { pop$ "2" } 957 | { skip$ } 958 | if$ 959 | s "third" = 960 | { pop$ "3" } 961 | { skip$ } 962 | if$ 963 | s "fourth" = 964 | { pop$ "4" } 965 | { skip$ } 966 | if$ 967 | s "fifth" = 968 | { pop$ "5" } 969 | { skip$ } 970 | if$ 971 | s "sixth" = 972 | { pop$ "6" } 973 | { skip$ } 974 | if$ 975 | s "seventh" = 976 | { pop$ "7" } 977 | { skip$ } 978 | if$ 979 | s "eighth" = 980 | { pop$ "8" } 981 | { skip$ } 982 | if$ 983 | s "ninth" = 984 | { pop$ "9" } 985 | { skip$ } 986 | if$ 987 | s "tenth" = 988 | { pop$ "10" } 989 | { skip$ } 990 | if$ 991 | } 992 | 993 | 994 | % Converts the string on the top of the stack to numerical 995 | % ordinal (e.g., "11th") form. 996 | FUNCTION {convert.edition} 997 | { duplicate$ empty$ 'skip$ 998 | { duplicate$ #1 #1 substring$ is.num 999 | { extract.num 1000 | num.to.ordinal 1001 | } 1002 | { word.to.num 1003 | duplicate$ #1 #1 substring$ is.num 1004 | { num.to.ordinal } 1005 | { "edition ordinal word " quote$ * edition * quote$ * 1006 | " may be too high (or improper) for conversion" * " in " * cite$ * warning$ 1007 | } 1008 | if$ 1009 | } 1010 | if$ 1011 | } 1012 | if$ 1013 | } 1014 | 1015 | 1016 | 1017 | 1018 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%% 1019 | %% LATEX BIBLIOGRAPHY CODE %% 1020 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%% 1021 | 1022 | FUNCTION {start.entry} 1023 | { newline$ 1024 | "\bibitem{" write$ 1025 | cite$ write$ 1026 | "}" write$ 1027 | newline$ 1028 | "" 1029 | initialize.prev.this.status 1030 | } 1031 | 1032 | % Here we write out all the LaTeX code that we will need. The most involved 1033 | % code sequences are those that control the alternate interword spacing and 1034 | % foreign language hyphenation patterns. The heavy use of \providecommand 1035 | % gives users a way to override the defaults. Special thanks to Javier Bezos, 1036 | % Johannes Braams, Robin Fairbairns, Heiko Oberdiek, Donald Arseneau and all 1037 | % the other gurus on comp.text.tex for their help and advice on the topic of 1038 | % \selectlanguage, Babel and BibTeX. 1039 | FUNCTION {begin.bib} 1040 | { "% Generated by IEEEtran.bst, version: " bst.file.version * " (" * bst.file.date * ")" * 1041 | write$ newline$ 1042 | preamble$ empty$ 'skip$ 1043 | { preamble$ write$ newline$ } 1044 | if$ 1045 | "\begin{thebibliography}{" longest.label * "}" * 1046 | write$ newline$ 1047 | "\providecommand{\url}[1]{#1}" 1048 | write$ newline$ 1049 | "\csname url@samestyle\endcsname" 1050 | write$ newline$ 1051 | "\providecommand{\newblock}{\relax}" 1052 | write$ newline$ 1053 | "\providecommand{\bibinfo}[2]{#2}" 1054 | write$ newline$ 1055 | "\providecommand{\BIBentrySTDinterwordspacing}{\spaceskip=0pt\relax}" 1056 | write$ newline$ 1057 | "\providecommand{\BIBentryALTinterwordstretchfactor}{" 1058 | ALTinterwordstretchfactor * "}" * 1059 | write$ newline$ 1060 | "\providecommand{\BIBentryALTinterwordspacing}{\spaceskip=\fontdimen2\font plus " 1061 | write$ newline$ 1062 | "\BIBentryALTinterwordstretchfactor\fontdimen3\font minus \fontdimen4\font\relax}" 1063 | write$ newline$ 1064 | "\providecommand{\BIBforeignlanguage}[2]{{%" 1065 | write$ newline$ 1066 | "\expandafter\ifx\csname l@#1\endcsname\relax" 1067 | write$ newline$ 1068 | "\typeout{** WARNING: IEEEtran.bst: No hyphenation pattern has been}%" 1069 | write$ newline$ 1070 | "\typeout{** loaded for the language `#1'. Using the pattern for}%" 1071 | write$ newline$ 1072 | "\typeout{** the default language instead.}%" 1073 | write$ newline$ 1074 | "\else" 1075 | write$ newline$ 1076 | "\language=\csname l@#1\endcsname" 1077 | write$ newline$ 1078 | "\fi" 1079 | write$ newline$ 1080 | "#2}}" 1081 | write$ newline$ 1082 | "\providecommand{\BIBdecl}{\relax}" 1083 | write$ newline$ 1084 | "\BIBdecl" 1085 | write$ newline$ 1086 | } 1087 | 1088 | FUNCTION {end.bib} 1089 | { newline$ "\end{thebibliography}" write$ newline$ } 1090 | 1091 | FUNCTION {if.url.alt.interword.spacing} 1092 | { is.use.alt.interword.spacing 1093 | { is.use.url 1094 | { url empty$ 'skip$ {"\BIBentryALTinterwordspacing" write$ newline$} if$ } 1095 | { skip$ } 1096 | if$ 1097 | } 1098 | { skip$ } 1099 | if$ 1100 | } 1101 | 1102 | FUNCTION {if.url.std.interword.spacing} 1103 | { is.use.alt.interword.spacing 1104 | { is.use.url 1105 | { url empty$ 'skip$ {"\BIBentrySTDinterwordspacing" write$ newline$} if$ } 1106 | { skip$ } 1107 | if$ 1108 | } 1109 | { skip$ } 1110 | if$ 1111 | } 1112 | 1113 | 1114 | 1115 | 1116 | %%%%%%%%%%%%%%%%%%%%%%%% 1117 | %% LONGEST LABEL PASS %% 1118 | %%%%%%%%%%%%%%%%%%%%%%%% 1119 | 1120 | FUNCTION {initialize.longest.label} 1121 | { "" 'longest.label := 1122 | #1 'number.label := 1123 | #0 'longest.label.width := 1124 | } 1125 | 1126 | FUNCTION {longest.label.pass} 1127 | { type$ "ieeetranbstctl" = 1128 | { skip$ } 1129 | { number.label int.to.str$ 'label := 1130 | number.label #1 + 'number.label := 1131 | label width$ longest.label.width > 1132 | { label 'longest.label := 1133 | label width$ 'longest.label.width := 1134 | } 1135 | { skip$ } 1136 | if$ 1137 | } 1138 | if$ 1139 | } 1140 | 1141 | 1142 | 1143 | 1144 | %%%%%%%%%%%%%%%%%%%%% 1145 | %% FORMAT HANDLERS %% 1146 | %%%%%%%%%%%%%%%%%%%%% 1147 | 1148 | %% Lower Level Formats (used by higher level formats) 1149 | 1150 | FUNCTION {format.address.org.or.pub.date} 1151 | { 't := 1152 | "" 1153 | year empty$ 1154 | { "empty year in " cite$ * warning$ } 1155 | { skip$ } 1156 | if$ 1157 | address empty$ t empty$ and 1158 | year empty$ and month empty$ and 1159 | { skip$ } 1160 | { this.to.prev.status 1161 | this.status.std 1162 | cap.status.std 1163 | address "address" bibinfo.check * 1164 | t empty$ 1165 | { skip$ } 1166 | { punct.period 'prev.status.punct := 1167 | space.large 'prev.status.space := 1168 | address empty$ 1169 | { skip$ } 1170 | { ": " * } 1171 | if$ 1172 | t * 1173 | } 1174 | if$ 1175 | year empty$ month empty$ and 1176 | { skip$ } 1177 | { t empty$ address empty$ and 1178 | { skip$ } 1179 | { ", " * } 1180 | if$ 1181 | month empty$ 1182 | { year empty$ 1183 | { skip$ } 1184 | { year "year" bibinfo.check * } 1185 | if$ 1186 | } 1187 | { month "month" bibinfo.check * 1188 | year empty$ 1189 | { skip$ } 1190 | { " " * year "year" bibinfo.check * } 1191 | if$ 1192 | } 1193 | if$ 1194 | } 1195 | if$ 1196 | } 1197 | if$ 1198 | } 1199 | 1200 | 1201 | FUNCTION {format.names} 1202 | { 'bibinfo := 1203 | duplicate$ empty$ 'skip$ { 1204 | this.to.prev.status 1205 | this.status.std 1206 | 's := 1207 | "" 't := 1208 | #1 'nameptr := 1209 | s num.names$ 'numnames := 1210 | numnames 'namesleft := 1211 | { namesleft #0 > } 1212 | { s nameptr 1213 | name.format.string 1214 | format.name$ 1215 | bibinfo bibinfo.check 1216 | 't := 1217 | nameptr #1 > 1218 | { nameptr num.names.shown.with.forced.et.al #1 + = 1219 | numnames max.num.names.before.forced.et.al > 1220 | is.forced.et.al and and 1221 | { "others" 't := 1222 | #1 'namesleft := 1223 | } 1224 | { skip$ } 1225 | if$ 1226 | namesleft #1 > 1227 | { ", " * t do.name.latex.cmd * } 1228 | { s nameptr "{ll}" format.name$ duplicate$ "others" = 1229 | { 't := } 1230 | { pop$ } 1231 | if$ 1232 | t "others" = 1233 | { " " * bbl.etal emphasize * } 1234 | { numnames #2 > 1235 | { "," * } 1236 | { skip$ } 1237 | if$ 1238 | bbl.and 1239 | space.word * t do.name.latex.cmd * 1240 | } 1241 | if$ 1242 | } 1243 | if$ 1244 | } 1245 | { t do.name.latex.cmd } 1246 | if$ 1247 | nameptr #1 + 'nameptr := 1248 | namesleft #1 - 'namesleft := 1249 | } 1250 | while$ 1251 | cap.status.std 1252 | } if$ 1253 | } 1254 | 1255 | 1256 | 1257 | 1258 | %% Higher Level Formats 1259 | 1260 | %% addresses/locations 1261 | 1262 | FUNCTION {format.address} 1263 | { address duplicate$ empty$ 'skip$ 1264 | { this.to.prev.status 1265 | this.status.std 1266 | cap.status.std 1267 | } 1268 | if$ 1269 | } 1270 | 1271 | 1272 | 1273 | %% author/editor names 1274 | 1275 | FUNCTION {format.authors}{ author "author" format.names } 1276 | 1277 | FUNCTION {format.editors} 1278 | { editor "editor" format.names duplicate$ empty$ 'skip$ 1279 | { ", " * 1280 | get.bbl.editor 1281 | capitalize 1282 | * 1283 | } 1284 | if$ 1285 | } 1286 | 1287 | 1288 | 1289 | %% date 1290 | 1291 | FUNCTION {format.date} 1292 | { 1293 | month "month" bibinfo.check duplicate$ empty$ 1294 | year "year" bibinfo.check duplicate$ empty$ 1295 | { swap$ 'skip$ 1296 | { this.to.prev.status 1297 | this.status.std 1298 | cap.status.std 1299 | "there's a month but no year in " cite$ * warning$ } 1300 | if$ 1301 | * 1302 | } 1303 | { this.to.prev.status 1304 | this.status.std 1305 | cap.status.std 1306 | swap$ 'skip$ 1307 | { 1308 | swap$ 1309 | " " * swap$ 1310 | } 1311 | if$ 1312 | * 1313 | } 1314 | if$ 1315 | } 1316 | 1317 | FUNCTION {format.date.electronic} 1318 | { month "month" bibinfo.check duplicate$ empty$ 1319 | year "year" bibinfo.check duplicate$ empty$ 1320 | { swap$ 1321 | { pop$ } 1322 | { "there's a month but no year in " cite$ * warning$ 1323 | pop$ ")" * "(" swap$ * 1324 | this.to.prev.status 1325 | punct.no 'this.status.punct := 1326 | space.normal 'this.status.space := 1327 | quote.no 'this.status.quote := 1328 | cap.yes 'status.cap := 1329 | } 1330 | if$ 1331 | } 1332 | { swap$ 1333 | { swap$ pop$ ")" * "(" swap$ * } 1334 | { "(" swap$ * ", " * swap$ * ")" * } 1335 | if$ 1336 | this.to.prev.status 1337 | punct.no 'this.status.punct := 1338 | space.normal 'this.status.space := 1339 | quote.no 'this.status.quote := 1340 | cap.yes 'status.cap := 1341 | } 1342 | if$ 1343 | } 1344 | 1345 | 1346 | 1347 | %% edition/title 1348 | 1349 | % Note: The IEEE considers the edition to be closely associated with 1350 | % the title of a book. So, in IEEEtran.bst the edition is normally handled 1351 | % within the formatting of the title. The format.edition function is 1352 | % retained here for possible future use. 1353 | FUNCTION {format.edition} 1354 | { edition duplicate$ empty$ 'skip$ 1355 | { this.to.prev.status 1356 | this.status.std 1357 | convert.edition 1358 | status.cap 1359 | { "t" } 1360 | { "l" } 1361 | if$ change.case$ 1362 | "edition" bibinfo.check 1363 | "~" * bbl.edition * 1364 | cap.status.std 1365 | } 1366 | if$ 1367 | } 1368 | 1369 | % This is used to format the booktitle of a conference proceedings. 1370 | % Here we use the "intype" field to provide the user a way to 1371 | % override the word "in" (e.g., with things like "presented at") 1372 | % Use of intype stops the emphasis of the booktitle to indicate that 1373 | % we no longer mean the written conference proceedings, but the 1374 | % conference itself. 1375 | FUNCTION {format.in.booktitle} 1376 | { booktitle "booktitle" bibinfo.check duplicate$ empty$ 'skip$ 1377 | { this.to.prev.status 1378 | this.status.std 1379 | select.language 1380 | intype missing$ 1381 | { emphasize 1382 | bbl.in " " * 1383 | } 1384 | { intype " " * } 1385 | if$ 1386 | swap$ * 1387 | cap.status.std 1388 | } 1389 | if$ 1390 | } 1391 | 1392 | % This is used to format the booktitle of collection. 1393 | % Here the "intype" field is not supported, but "edition" is. 1394 | FUNCTION {format.in.booktitle.edition} 1395 | { booktitle "booktitle" bibinfo.check duplicate$ empty$ 'skip$ 1396 | { this.to.prev.status 1397 | this.status.std 1398 | select.language 1399 | emphasize 1400 | edition empty$ 'skip$ 1401 | { ", " * 1402 | edition 1403 | convert.edition 1404 | "l" change.case$ 1405 | * "~" * bbl.edition * 1406 | } 1407 | if$ 1408 | bbl.in " " * swap$ * 1409 | cap.status.std 1410 | } 1411 | if$ 1412 | } 1413 | 1414 | FUNCTION {format.article.title} 1415 | { title duplicate$ empty$ 'skip$ 1416 | { this.to.prev.status 1417 | this.status.std 1418 | "t" change.case$ 1419 | } 1420 | if$ 1421 | "title" bibinfo.check 1422 | duplicate$ empty$ 'skip$ 1423 | { quote.close 'this.status.quote := 1424 | is.last.char.not.punct 1425 | { punct.std 'this.status.punct := } 1426 | { punct.no 'this.status.punct := } 1427 | if$ 1428 | select.language 1429 | "``" swap$ * 1430 | cap.status.std 1431 | } 1432 | if$ 1433 | } 1434 | 1435 | FUNCTION {format.article.title.electronic} 1436 | { title duplicate$ empty$ 'skip$ 1437 | { this.to.prev.status 1438 | this.status.std 1439 | cap.status.std 1440 | "t" change.case$ 1441 | } 1442 | if$ 1443 | "title" bibinfo.check 1444 | duplicate$ empty$ 1445 | { skip$ } 1446 | { select.language } 1447 | if$ 1448 | } 1449 | 1450 | FUNCTION {format.book.title.edition} 1451 | { title "title" bibinfo.check 1452 | duplicate$ empty$ 1453 | { "empty title in " cite$ * warning$ } 1454 | { this.to.prev.status 1455 | this.status.std 1456 | select.language 1457 | emphasize 1458 | edition empty$ 'skip$ 1459 | { ", " * 1460 | edition 1461 | convert.edition 1462 | status.cap 1463 | { "t" } 1464 | { "l" } 1465 | if$ 1466 | change.case$ 1467 | * "~" * bbl.edition * 1468 | } 1469 | if$ 1470 | cap.status.std 1471 | } 1472 | if$ 1473 | } 1474 | 1475 | FUNCTION {format.book.title} 1476 | { title "title" bibinfo.check 1477 | duplicate$ empty$ 'skip$ 1478 | { this.to.prev.status 1479 | this.status.std 1480 | cap.status.std 1481 | select.language 1482 | emphasize 1483 | } 1484 | if$ 1485 | } 1486 | 1487 | 1488 | 1489 | %% journal 1490 | 1491 | FUNCTION {format.journal} 1492 | { journal duplicate$ empty$ 'skip$ 1493 | { this.to.prev.status 1494 | this.status.std 1495 | cap.status.std 1496 | select.language 1497 | emphasize 1498 | } 1499 | if$ 1500 | } 1501 | 1502 | 1503 | 1504 | %% how published 1505 | 1506 | FUNCTION {format.howpublished} 1507 | { howpublished duplicate$ empty$ 'skip$ 1508 | { this.to.prev.status 1509 | this.status.std 1510 | cap.status.std 1511 | } 1512 | if$ 1513 | } 1514 | 1515 | 1516 | 1517 | %% institutions/organization/publishers/school 1518 | 1519 | FUNCTION {format.institution} 1520 | { institution duplicate$ empty$ 'skip$ 1521 | { this.to.prev.status 1522 | this.status.std 1523 | cap.status.std 1524 | } 1525 | if$ 1526 | } 1527 | 1528 | FUNCTION {format.organization} 1529 | { organization duplicate$ empty$ 'skip$ 1530 | { this.to.prev.status 1531 | this.status.std 1532 | cap.status.std 1533 | } 1534 | if$ 1535 | } 1536 | 1537 | FUNCTION {format.address.publisher.date} 1538 | { publisher "publisher" bibinfo.warn format.address.org.or.pub.date } 1539 | 1540 | FUNCTION {format.address.publisher.date.nowarn} 1541 | { publisher "publisher" bibinfo.check format.address.org.or.pub.date } 1542 | 1543 | FUNCTION {format.address.organization.date} 1544 | { organization "organization" bibinfo.check format.address.org.or.pub.date } 1545 | 1546 | FUNCTION {format.school} 1547 | { school duplicate$ empty$ 'skip$ 1548 | { this.to.prev.status 1549 | this.status.std 1550 | cap.status.std 1551 | } 1552 | if$ 1553 | } 1554 | 1555 | 1556 | 1557 | %% volume/number/series/chapter/pages 1558 | 1559 | FUNCTION {format.volume} 1560 | { volume empty.field.to.null.string 1561 | duplicate$ empty$ 'skip$ 1562 | { this.to.prev.status 1563 | this.status.std 1564 | bbl.volume 1565 | status.cap 1566 | { capitalize } 1567 | { skip$ } 1568 | if$ 1569 | swap$ tie.or.space.prefix 1570 | "volume" bibinfo.check 1571 | * * 1572 | cap.status.std 1573 | } 1574 | if$ 1575 | } 1576 | 1577 | FUNCTION {format.number} 1578 | { number empty.field.to.null.string 1579 | duplicate$ empty$ 'skip$ 1580 | { this.to.prev.status 1581 | this.status.std 1582 | status.cap 1583 | { bbl.number capitalize } 1584 | { bbl.number } 1585 | if$ 1586 | swap$ tie.or.space.prefix 1587 | "number" bibinfo.check 1588 | * * 1589 | cap.status.std 1590 | } 1591 | if$ 1592 | } 1593 | 1594 | FUNCTION {format.number.if.use.for.article} 1595 | { is.use.number.for.article 1596 | { format.number } 1597 | { "" } 1598 | if$ 1599 | } 1600 | 1601 | % The IEEE does not seem to tie the series so closely with the volume 1602 | % and number as is done in other bibliography styles. Instead the 1603 | % series is treated somewhat like an extension of the title. 1604 | FUNCTION {format.series} 1605 | { series empty$ 1606 | { "" } 1607 | { this.to.prev.status 1608 | this.status.std 1609 | bbl.series " " * 1610 | series "series" bibinfo.check * 1611 | cap.status.std 1612 | } 1613 | if$ 1614 | } 1615 | 1616 | 1617 | FUNCTION {format.chapter} 1618 | { chapter empty$ 1619 | { "" } 1620 | { this.to.prev.status 1621 | this.status.std 1622 | type empty$ 1623 | { bbl.chapter } 1624 | { type "l" change.case$ 1625 | "type" bibinfo.check 1626 | } 1627 | if$ 1628 | chapter tie.or.space.prefix 1629 | "chapter" bibinfo.check 1630 | * * 1631 | cap.status.std 1632 | } 1633 | if$ 1634 | } 1635 | 1636 | 1637 | % The intended use of format.paper is for paper numbers of inproceedings. 1638 | % The paper type can be overridden via the type field. 1639 | % We allow the type to be displayed even if the paper number is absent 1640 | % for things like "postdeadline paper" 1641 | FUNCTION {format.paper} 1642 | { is.use.paper 1643 | { paper empty$ 1644 | { type empty$ 1645 | { "" } 1646 | { this.to.prev.status 1647 | this.status.std 1648 | type "type" bibinfo.check 1649 | cap.status.std 1650 | } 1651 | if$ 1652 | } 1653 | { this.to.prev.status 1654 | this.status.std 1655 | type empty$ 1656 | { bbl.paper } 1657 | { type "type" bibinfo.check } 1658 | if$ 1659 | " " * paper 1660 | "paper" bibinfo.check 1661 | * 1662 | cap.status.std 1663 | } 1664 | if$ 1665 | } 1666 | { "" } 1667 | if$ 1668 | } 1669 | 1670 | 1671 | FUNCTION {format.pages} 1672 | { pages duplicate$ empty$ 'skip$ 1673 | { this.to.prev.status 1674 | this.status.std 1675 | duplicate$ is.multiple.pages 1676 | { 1677 | bbl.pages swap$ 1678 | n.dashify 1679 | } 1680 | { 1681 | bbl.page swap$ 1682 | } 1683 | if$ 1684 | tie.or.space.prefix 1685 | "pages" bibinfo.check 1686 | * * 1687 | cap.status.std 1688 | } 1689 | if$ 1690 | } 1691 | 1692 | 1693 | 1694 | %% technical report number 1695 | 1696 | FUNCTION {format.tech.report.number} 1697 | { number "number" bibinfo.check 1698 | this.to.prev.status 1699 | this.status.std 1700 | cap.status.std 1701 | type duplicate$ empty$ 1702 | { pop$ 1703 | bbl.techrep 1704 | } 1705 | { skip$ } 1706 | if$ 1707 | "type" bibinfo.check 1708 | swap$ duplicate$ empty$ 1709 | { pop$ } 1710 | { tie.or.space.prefix * * } 1711 | if$ 1712 | } 1713 | 1714 | 1715 | 1716 | %% note 1717 | 1718 | FUNCTION {format.note} 1719 | { note empty$ 1720 | { "" } 1721 | { this.to.prev.status 1722 | this.status.std 1723 | punct.period 'this.status.punct := 1724 | note #1 #1 substring$ 1725 | duplicate$ "{" = 1726 | { skip$ } 1727 | { status.cap 1728 | { "u" } 1729 | { "l" } 1730 | if$ 1731 | change.case$ 1732 | } 1733 | if$ 1734 | note #2 global.max$ substring$ * "note" bibinfo.check 1735 | cap.yes 'status.cap := 1736 | } 1737 | if$ 1738 | } 1739 | 1740 | 1741 | 1742 | %% patent 1743 | 1744 | FUNCTION {format.patent.date} 1745 | { this.to.prev.status 1746 | this.status.std 1747 | year empty$ 1748 | { monthfiled duplicate$ empty$ 1749 | { "monthfiled" bibinfo.check pop$ "" } 1750 | { "monthfiled" bibinfo.check } 1751 | if$ 1752 | dayfiled duplicate$ empty$ 1753 | { "dayfiled" bibinfo.check pop$ "" * } 1754 | { "dayfiled" bibinfo.check 1755 | monthfiled empty$ 1756 | { "dayfiled without a monthfiled in " cite$ * warning$ 1757 | * 1758 | } 1759 | { " " swap$ * * } 1760 | if$ 1761 | } 1762 | if$ 1763 | yearfiled empty$ 1764 | { "no year or yearfiled in " cite$ * warning$ } 1765 | { yearfiled "yearfiled" bibinfo.check 1766 | swap$ 1767 | duplicate$ empty$ 1768 | { pop$ } 1769 | { ", " * swap$ * } 1770 | if$ 1771 | } 1772 | if$ 1773 | } 1774 | { month duplicate$ empty$ 1775 | { "month" bibinfo.check pop$ "" } 1776 | { "month" bibinfo.check } 1777 | if$ 1778 | day duplicate$ empty$ 1779 | { "day" bibinfo.check pop$ "" * } 1780 | { "day" bibinfo.check 1781 | month empty$ 1782 | { "day without a month in " cite$ * warning$ 1783 | * 1784 | } 1785 | { " " swap$ * * } 1786 | if$ 1787 | } 1788 | if$ 1789 | year "year" bibinfo.check 1790 | swap$ 1791 | duplicate$ empty$ 1792 | { pop$ } 1793 | { ", " * swap$ * } 1794 | if$ 1795 | } 1796 | if$ 1797 | cap.status.std 1798 | } 1799 | 1800 | FUNCTION {format.patent.nationality.type.number} 1801 | { this.to.prev.status 1802 | this.status.std 1803 | nationality duplicate$ empty$ 1804 | { "nationality" bibinfo.warn pop$ "" } 1805 | { "nationality" bibinfo.check 1806 | duplicate$ "l" change.case$ "united states" = 1807 | { pop$ bbl.patentUS } 1808 | { skip$ } 1809 | if$ 1810 | " " * 1811 | } 1812 | if$ 1813 | type empty$ 1814 | { bbl.patent "type" bibinfo.check } 1815 | { type "type" bibinfo.check } 1816 | if$ 1817 | * 1818 | number duplicate$ empty$ 1819 | { "number" bibinfo.warn pop$ } 1820 | { "number" bibinfo.check 1821 | large.number.separate 1822 | swap$ " " * swap$ * 1823 | } 1824 | if$ 1825 | cap.status.std 1826 | } 1827 | 1828 | 1829 | 1830 | %% standard 1831 | 1832 | FUNCTION {format.organization.institution.standard.type.number} 1833 | { this.to.prev.status 1834 | this.status.std 1835 | organization duplicate$ empty$ 1836 | { pop$ 1837 | institution duplicate$ empty$ 1838 | { "institution" bibinfo.warn } 1839 | { "institution" bibinfo.warn " " * } 1840 | if$ 1841 | } 1842 | { "organization" bibinfo.warn " " * } 1843 | if$ 1844 | type empty$ 1845 | { bbl.standard "type" bibinfo.check } 1846 | { type "type" bibinfo.check } 1847 | if$ 1848 | * 1849 | number duplicate$ empty$ 1850 | { "number" bibinfo.check pop$ } 1851 | { "number" bibinfo.check 1852 | large.number.separate 1853 | swap$ " " * swap$ * 1854 | } 1855 | if$ 1856 | cap.status.std 1857 | } 1858 | 1859 | FUNCTION {format.revision} 1860 | { revision empty$ 1861 | { "" } 1862 | { this.to.prev.status 1863 | this.status.std 1864 | bbl.revision 1865 | revision tie.or.space.prefix 1866 | "revision" bibinfo.check 1867 | * * 1868 | cap.status.std 1869 | } 1870 | if$ 1871 | } 1872 | 1873 | 1874 | %% thesis 1875 | 1876 | FUNCTION {format.master.thesis.type} 1877 | { this.to.prev.status 1878 | this.status.std 1879 | type empty$ 1880 | { 1881 | bbl.mthesis 1882 | } 1883 | { 1884 | type "type" bibinfo.check 1885 | } 1886 | if$ 1887 | cap.status.std 1888 | } 1889 | 1890 | FUNCTION {format.phd.thesis.type} 1891 | { this.to.prev.status 1892 | this.status.std 1893 | type empty$ 1894 | { 1895 | bbl.phdthesis 1896 | } 1897 | { 1898 | type "type" bibinfo.check 1899 | } 1900 | if$ 1901 | cap.status.std 1902 | } 1903 | 1904 | 1905 | 1906 | %% URL 1907 | 1908 | FUNCTION {format.url} 1909 | { is.use.url 1910 | { url empty$ 1911 | { "" } 1912 | { this.to.prev.status 1913 | this.status.std 1914 | cap.yes 'status.cap := 1915 | name.url.prefix " " * 1916 | "\url{" * url * "}" * 1917 | punct.no 'this.status.punct := 1918 | punct.period 'prev.status.punct := 1919 | space.normal 'this.status.space := 1920 | space.normal 'prev.status.space := 1921 | quote.no 'this.status.quote := 1922 | } 1923 | if$ 1924 | } 1925 | { "" } 1926 | if$ 1927 | } 1928 | 1929 | 1930 | 1931 | 1932 | %%%%%%%%%%%%%%%%%%%% 1933 | %% ENTRY HANDLERS %% 1934 | %%%%%%%%%%%%%%%%%%%% 1935 | 1936 | 1937 | % Note: In many journals, the IEEE (or the authors) tend not to show the number 1938 | % for articles, so the display of the number is controlled here by the 1939 | % switch "is.use.number.for.article" 1940 | FUNCTION {article} 1941 | { std.status.using.comma 1942 | start.entry 1943 | if.url.alt.interword.spacing 1944 | format.authors "author" output.warn 1945 | name.or.dash 1946 | format.article.title "title" output.warn 1947 | format.journal "journal" bibinfo.check "journal" output.warn 1948 | format.volume output 1949 | format.number.if.use.for.article output 1950 | format.pages output 1951 | format.date "year" output.warn 1952 | format.note output 1953 | format.url output 1954 | fin.entry 1955 | if.url.std.interword.spacing 1956 | } 1957 | 1958 | FUNCTION {book} 1959 | { std.status.using.comma 1960 | start.entry 1961 | if.url.alt.interword.spacing 1962 | author empty$ 1963 | { format.editors "author and editor" output.warn } 1964 | { format.authors output.nonnull } 1965 | if$ 1966 | name.or.dash 1967 | format.book.title.edition output 1968 | format.series output 1969 | author empty$ 1970 | { skip$ } 1971 | { format.editors output } 1972 | if$ 1973 | format.address.publisher.date output 1974 | format.volume output 1975 | format.number output 1976 | format.note output 1977 | format.url output 1978 | fin.entry 1979 | if.url.std.interword.spacing 1980 | } 1981 | 1982 | FUNCTION {booklet} 1983 | { std.status.using.comma 1984 | start.entry 1985 | if.url.alt.interword.spacing 1986 | format.authors output 1987 | name.or.dash 1988 | format.article.title "title" output.warn 1989 | format.howpublished "howpublished" bibinfo.check output 1990 | format.organization "organization" bibinfo.check output 1991 | format.address "address" bibinfo.check output 1992 | format.date output 1993 | format.note output 1994 | format.url output 1995 | fin.entry 1996 | if.url.std.interword.spacing 1997 | } 1998 | 1999 | FUNCTION {electronic} 2000 | { std.status.using.period 2001 | start.entry 2002 | if.url.alt.interword.spacing 2003 | format.authors output 2004 | name.or.dash 2005 | format.date.electronic output 2006 | format.article.title.electronic output 2007 | format.howpublished "howpublished" bibinfo.check output 2008 | format.organization "organization" bibinfo.check output 2009 | format.address "address" bibinfo.check output 2010 | format.note output 2011 | format.url output 2012 | fin.entry 2013 | empty.entry.warn 2014 | if.url.std.interword.spacing 2015 | } 2016 | 2017 | FUNCTION {inbook} 2018 | { std.status.using.comma 2019 | start.entry 2020 | if.url.alt.interword.spacing 2021 | author empty$ 2022 | { format.editors "author and editor" output.warn } 2023 | { format.authors output.nonnull } 2024 | if$ 2025 | name.or.dash 2026 | format.book.title.edition output 2027 | format.series output 2028 | format.address.publisher.date output 2029 | format.volume output 2030 | format.number output 2031 | format.chapter output 2032 | format.pages output 2033 | format.note output 2034 | format.url output 2035 | fin.entry 2036 | if.url.std.interword.spacing 2037 | } 2038 | 2039 | FUNCTION {incollection} 2040 | { std.status.using.comma 2041 | start.entry 2042 | if.url.alt.interword.spacing 2043 | format.authors "author" output.warn 2044 | name.or.dash 2045 | format.article.title "title" output.warn 2046 | format.in.booktitle.edition "booktitle" output.warn 2047 | format.series output 2048 | format.editors output 2049 | format.address.publisher.date.nowarn output 2050 | format.volume output 2051 | format.number output 2052 | format.chapter output 2053 | format.pages output 2054 | format.note output 2055 | format.url output 2056 | fin.entry 2057 | if.url.std.interword.spacing 2058 | } 2059 | 2060 | FUNCTION {inproceedings} 2061 | { std.status.using.comma 2062 | start.entry 2063 | if.url.alt.interword.spacing 2064 | format.authors "author" output.warn 2065 | name.or.dash 2066 | format.article.title "title" output.warn 2067 | format.in.booktitle "booktitle" output.warn 2068 | format.series output 2069 | format.editors output 2070 | format.volume output 2071 | format.number output 2072 | publisher empty$ 2073 | { format.address.organization.date output } 2074 | { format.organization "organization" bibinfo.check output 2075 | format.address.publisher.date output 2076 | } 2077 | if$ 2078 | format.paper output 2079 | format.pages output 2080 | format.note output 2081 | format.url output 2082 | fin.entry 2083 | if.url.std.interword.spacing 2084 | } 2085 | 2086 | FUNCTION {manual} 2087 | { std.status.using.comma 2088 | start.entry 2089 | if.url.alt.interword.spacing 2090 | format.authors output 2091 | name.or.dash 2092 | format.book.title.edition "title" output.warn 2093 | format.howpublished "howpublished" bibinfo.check output 2094 | format.organization "organization" bibinfo.check output 2095 | format.address "address" bibinfo.check output 2096 | format.date output 2097 | format.note output 2098 | format.url output 2099 | fin.entry 2100 | if.url.std.interword.spacing 2101 | } 2102 | 2103 | FUNCTION {mastersthesis} 2104 | { std.status.using.comma 2105 | start.entry 2106 | if.url.alt.interword.spacing 2107 | format.authors "author" output.warn 2108 | name.or.dash 2109 | format.article.title "title" output.warn 2110 | format.master.thesis.type output.nonnull 2111 | format.school "school" bibinfo.warn output 2112 | format.address "address" bibinfo.check output 2113 | format.date "year" output.warn 2114 | format.note output 2115 | format.url output 2116 | fin.entry 2117 | if.url.std.interword.spacing 2118 | } 2119 | 2120 | FUNCTION {misc} 2121 | { std.status.using.comma 2122 | start.entry 2123 | if.url.alt.interword.spacing 2124 | format.authors output 2125 | name.or.dash 2126 | format.article.title output 2127 | format.howpublished "howpublished" bibinfo.check output 2128 | format.organization "organization" bibinfo.check output 2129 | format.address "address" bibinfo.check output 2130 | format.pages output 2131 | format.date output 2132 | format.note output 2133 | format.url output 2134 | fin.entry 2135 | empty.entry.warn 2136 | if.url.std.interword.spacing 2137 | } 2138 | 2139 | FUNCTION {patent} 2140 | { std.status.using.comma 2141 | start.entry 2142 | if.url.alt.interword.spacing 2143 | format.authors output 2144 | name.or.dash 2145 | format.article.title output 2146 | format.patent.nationality.type.number output 2147 | format.patent.date output 2148 | format.note output 2149 | format.url output 2150 | fin.entry 2151 | empty.entry.warn 2152 | if.url.std.interword.spacing 2153 | } 2154 | 2155 | FUNCTION {periodical} 2156 | { std.status.using.comma 2157 | start.entry 2158 | if.url.alt.interword.spacing 2159 | format.editors output 2160 | name.or.dash 2161 | format.book.title "title" output.warn 2162 | format.series output 2163 | format.volume output 2164 | format.number output 2165 | format.organization "organization" bibinfo.check output 2166 | format.date "year" output.warn 2167 | format.note output 2168 | format.url output 2169 | fin.entry 2170 | if.url.std.interword.spacing 2171 | } 2172 | 2173 | FUNCTION {phdthesis} 2174 | { std.status.using.comma 2175 | start.entry 2176 | if.url.alt.interword.spacing 2177 | format.authors "author" output.warn 2178 | name.or.dash 2179 | format.article.title "title" output.warn 2180 | format.phd.thesis.type output.nonnull 2181 | format.school "school" bibinfo.warn output 2182 | format.address "address" bibinfo.check output 2183 | format.date "year" output.warn 2184 | format.note output 2185 | format.url output 2186 | fin.entry 2187 | if.url.std.interword.spacing 2188 | } 2189 | 2190 | FUNCTION {proceedings} 2191 | { std.status.using.comma 2192 | start.entry 2193 | if.url.alt.interword.spacing 2194 | format.editors output 2195 | name.or.dash 2196 | format.book.title "title" output.warn 2197 | format.series output 2198 | format.volume output 2199 | format.number output 2200 | publisher empty$ 2201 | { format.address.organization.date output } 2202 | { format.organization "organization" bibinfo.check output 2203 | format.address.publisher.date output 2204 | } 2205 | if$ 2206 | format.note output 2207 | format.url output 2208 | fin.entry 2209 | if.url.std.interword.spacing 2210 | } 2211 | 2212 | FUNCTION {standard} 2213 | { std.status.using.comma 2214 | start.entry 2215 | if.url.alt.interword.spacing 2216 | format.authors output 2217 | name.or.dash 2218 | format.book.title "title" output.warn 2219 | format.howpublished "howpublished" bibinfo.check output 2220 | format.organization.institution.standard.type.number output 2221 | format.revision output 2222 | format.date output 2223 | format.note output 2224 | format.url output 2225 | fin.entry 2226 | if.url.std.interword.spacing 2227 | } 2228 | 2229 | FUNCTION {techreport} 2230 | { std.status.using.comma 2231 | start.entry 2232 | if.url.alt.interword.spacing 2233 | format.authors "author" output.warn 2234 | name.or.dash 2235 | format.article.title "title" output.warn 2236 | format.howpublished "howpublished" bibinfo.check output 2237 | format.institution "institution" bibinfo.warn output 2238 | format.address "address" bibinfo.check output 2239 | format.tech.report.number output.nonnull 2240 | format.date "year" output.warn 2241 | format.note output 2242 | format.url output 2243 | fin.entry 2244 | if.url.std.interword.spacing 2245 | } 2246 | 2247 | FUNCTION {unpublished} 2248 | { std.status.using.comma 2249 | start.entry 2250 | if.url.alt.interword.spacing 2251 | format.authors "author" output.warn 2252 | name.or.dash 2253 | format.article.title "title" output.warn 2254 | format.date output 2255 | format.note "note" output.warn 2256 | format.url output 2257 | fin.entry 2258 | if.url.std.interword.spacing 2259 | } 2260 | 2261 | 2262 | % The special entry type which provides the user interface to the 2263 | % BST controls 2264 | FUNCTION {IEEEtranBSTCTL} 2265 | { is.print.banners.to.terminal 2266 | { "** IEEEtran BST control entry " quote$ * cite$ * quote$ * " detected." * 2267 | top$ 2268 | } 2269 | { skip$ } 2270 | if$ 2271 | CTLuse_article_number 2272 | empty$ 2273 | { skip$ } 2274 | { CTLuse_article_number 2275 | yes.no.to.int 2276 | 'is.use.number.for.article := 2277 | } 2278 | if$ 2279 | CTLuse_paper 2280 | empty$ 2281 | { skip$ } 2282 | { CTLuse_paper 2283 | yes.no.to.int 2284 | 'is.use.paper := 2285 | } 2286 | if$ 2287 | CTLuse_url 2288 | empty$ 2289 | { skip$ } 2290 | { CTLuse_url 2291 | yes.no.to.int 2292 | 'is.use.url := 2293 | } 2294 | if$ 2295 | CTLuse_forced_etal 2296 | empty$ 2297 | { skip$ } 2298 | { CTLuse_forced_etal 2299 | yes.no.to.int 2300 | 'is.forced.et.al := 2301 | } 2302 | if$ 2303 | CTLmax_names_forced_etal 2304 | empty$ 2305 | { skip$ } 2306 | { CTLmax_names_forced_etal 2307 | string.to.integer 2308 | 'max.num.names.before.forced.et.al := 2309 | } 2310 | if$ 2311 | CTLnames_show_etal 2312 | empty$ 2313 | { skip$ } 2314 | { CTLnames_show_etal 2315 | string.to.integer 2316 | 'num.names.shown.with.forced.et.al := 2317 | } 2318 | if$ 2319 | CTLuse_alt_spacing 2320 | empty$ 2321 | { skip$ } 2322 | { CTLuse_alt_spacing 2323 | yes.no.to.int 2324 | 'is.use.alt.interword.spacing := 2325 | } 2326 | if$ 2327 | CTLalt_stretch_factor 2328 | empty$ 2329 | { skip$ } 2330 | { CTLalt_stretch_factor 2331 | 'ALTinterwordstretchfactor := 2332 | "\renewcommand{\BIBentryALTinterwordstretchfactor}{" 2333 | ALTinterwordstretchfactor * "}" * 2334 | write$ newline$ 2335 | } 2336 | if$ 2337 | CTLdash_repeated_names 2338 | empty$ 2339 | { skip$ } 2340 | { CTLdash_repeated_names 2341 | yes.no.to.int 2342 | 'is.dash.repeated.names := 2343 | } 2344 | if$ 2345 | CTLname_format_string 2346 | empty$ 2347 | { skip$ } 2348 | { CTLname_format_string 2349 | 'name.format.string := 2350 | } 2351 | if$ 2352 | CTLname_latex_cmd 2353 | empty$ 2354 | { skip$ } 2355 | { CTLname_latex_cmd 2356 | 'name.latex.cmd := 2357 | } 2358 | if$ 2359 | CTLname_url_prefix 2360 | missing$ 2361 | { skip$ } 2362 | { CTLname_url_prefix 2363 | 'name.url.prefix := 2364 | } 2365 | if$ 2366 | 2367 | 2368 | num.names.shown.with.forced.et.al max.num.names.before.forced.et.al > 2369 | { "CTLnames_show_etal cannot be greater than CTLmax_names_forced_etal in " cite$ * warning$ 2370 | max.num.names.before.forced.et.al 'num.names.shown.with.forced.et.al := 2371 | } 2372 | { skip$ } 2373 | if$ 2374 | } 2375 | 2376 | 2377 | %%%%%%%%%%%%%%%%%%% 2378 | %% ENTRY ALIASES %% 2379 | %%%%%%%%%%%%%%%%%%% 2380 | FUNCTION {conference}{inproceedings} 2381 | FUNCTION {online}{electronic} 2382 | FUNCTION {internet}{electronic} 2383 | FUNCTION {webpage}{electronic} 2384 | FUNCTION {www}{electronic} 2385 | FUNCTION {default.type}{misc} 2386 | 2387 | 2388 | 2389 | %%%%%%%%%%%%%%%%%% 2390 | %% MAIN PROGRAM %% 2391 | %%%%%%%%%%%%%%%%%% 2392 | 2393 | READ 2394 | 2395 | EXECUTE {initialize.controls} 2396 | EXECUTE {initialize.status.constants} 2397 | EXECUTE {banner.message} 2398 | 2399 | EXECUTE {initialize.longest.label} 2400 | ITERATE {longest.label.pass} 2401 | 2402 | EXECUTE {begin.bib} 2403 | ITERATE {call.type$} 2404 | EXECUTE {end.bib} 2405 | 2406 | EXECUTE{completed.message} 2407 | 2408 | 2409 | %% That's all folks, mds. -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | all: 2 | pdflatex cbc-casper-paper-draft.tex && \ 3 | bibtex cbc-casper-paper-draft && \ 4 | pdflatex cbc-casper-paper-draft.tex && \ 5 | pdflatex cbc-casper-paper-draft.tex && \ 6 | rm -rf *.aux *.log *.out *.bbl *.blg *.toc; 7 | 8 | clean: 9 | rm cbc-casper-paper-draft.pdf 10 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Introducing the "minimal" CBC Casper Consensus Protocols. 2 | 3 | CBC Casper is a family of "correct-by-construction" consensus protocols that share the same proof of asynchronous, Byzantine fault tolerant consensus safety. We describe this family of protocols by defining their protocol states and protocol state transitions, and then we provide a proof of Byzantine fault tolerant consensus safety for the entire Minimal CBC Casper family of protocols. We give examples of members of this family of protocols, including a binary consensus protocol. "Casper the Friendly Ghost", a blockchain consensus protocol, and a sharded blockchain consensus protocol. Each of these examples is "correct-by-construction" because the way they are defined guarantees that they are part of this family of protocols, and therefore satisfy the consensus safety theorem. This draft is intended to be introductory and educational, it is not a complete description of a system that can be implemented exactly as specified. 4 | -------------------------------------------------------------------------------- /appendix.tex: -------------------------------------------------------------------------------- 1 | \section{Appendix} 2 | 3 | Here we give two concise equivalent definitions of the Minimal CBC Casper protocol states definition. They are less readable than the presentation given in the paper, but might be of interests to some readers. 4 | 5 | Both of the definitions given here use the same ``parameters" as presented in this draft. 6 | 7 | \begin{align} 8 | &\text{Consensus Values : } && \mathcal{C} \in SET ~ \land ~ \mathcal{C} \neq \emptyset \\ 9 | &\text{Validators : } && \mathcal{V} \in SET ~ \land ~ \mathcal{V} \neq \emptyset\\ 10 | &\text{Estimator : } &&\mathcal{E}: SET \to \mathcal{P}(\mathcal{C}) \\ 11 | &\text{Validator Weights : } &&\mathcal{W}: \mathcal{V} \to \mathbb{R}_+ \\ 12 | &\text{Equivocation Fault Tolerance Threshold : } && t \in \mathbb{R} \land 0 \leq t < \sum_{v \in \mathcal{V}} \mathcal{W}(v) 13 | \end{align} 14 | 15 | The first definition is almost exactly the definition given in the draft, but it in-lines definitions and uses pattern matching. Instead of defining intermediate states $\Sigma$ and then actual protocol states $\Sigma_t$, we directly define $\Gamma = \Sigma_t$: 16 | 17 | \begin{align} 18 | \Gamma_0 &= \{\emptyset\} \\ 19 | M_n &= \{ (c, v, \gamma) \in \mathcal{C} \times \mathcal{V} \times \Gamma_{n} : c \in \mathcal{E}(\gamma) \} \\ 20 | \Gamma_n &= \{ \gamma \in \mathcal{P}_{finite}(M_{n-1}) : (c, v, \gamma') \in \gamma \implies \gamma' \subseteq \gamma \\ 21 | &~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\land \sum_{ \substack{v \in \mathcal{V} : \\ \exists (c_1 , v, \gamma_1), (c_2 , v, \gamma_2) \in \gamma^2, \\ c_1 \neq c_2 \lor \gamma_1 \neq \gamma_2 \\ (c_2 , v, \gamma_2) \notin \gamma_1 ~\land ~ (c_1 , v, \gamma_1) \notin \gamma_2}} \mathcal{W}(v) \leq t \} ~~~~~~~~~~~~~~~~\text{ for $n > 0$} \\ 22 | M &= \bigcup_{n = 0}^\infty M_n \\ 23 | \Gamma &= \bigcup_{n = 0}^\infty \Gamma_n \\ 24 | \end{align} 25 | 26 | The second definition is as a fixed point of a function/action that adds protocol messages to protocol states (but only adds them if the fault weight is not pushed beyond the equivocation fault tolerance threshold $t$), namely: 27 | 28 | \begin{align}s 29 | f(X) &= X \cup \bigcup_{\substack{(\gamma, \gamma') \in X^2 : \\ \gamma \subseteq \gamma' \\ c \in \mathcal{E}(\gamma) \\ v \in \mathcal{V}}} 30 | \begin{cases} 31 | \{\gamma' \cup \{(c, v, \gamma)\} \} &, \text{ if } \sum_{ \substack{v' \in \mathcal{V} : \\ \exists (c_1 , v', \gamma_1), (c_2 , v', \gamma_2) \in (\gamma' \cup \{(c, v, \gamma)\})^2 \\ c_1 \neq c_2 ~ \lor ~ \gamma_1 \neq \gamma_2 \\ (c_2 , v', \gamma_2) \notin \gamma_1 \land (c_1 , v', \gamma_1) \notin \gamma_2}} \mathcal{W}(v') \leq t \\ 32 | \{\gamma'\} &, \text{ otherwise } 33 | \end{cases} 34 | \end{align} 35 | 36 | The protocol states can be defined as the following fixed point, which the result of applying our function $f$ to ``initial'' protocol state $\emptyset$ a countable infinite number of times. 37 | 38 | \[ 39 | \Gamma = \text{ fix } f ~ \{\emptyset\} = f(f(f(f(f(\dots f(f(\{\emptyset\}))\dots))))) 40 | \] 41 | 42 | And the messages are the elements of the protocol states: 43 | 44 | \[ 45 | M = \bigcup_{\substack{\gamma \in \Gamma \\ m \in \gamma}} \{m\} 46 | \] 47 | -------------------------------------------------------------------------------- /cbc-casper-paper-draft.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbc-casper/cbc-casper-paper/acc66e2ba4461a005262e2d5f434fd2e30ef0ff3/cbc-casper-paper-draft.pdf -------------------------------------------------------------------------------- /cbc-casper-paper-draft.tex: -------------------------------------------------------------------------------- 1 | \documentclass{article} 2 | \usepackage{graphicx} 3 | \usepackage{amsthm} 4 | \usepackage{amsmath} 5 | \usepackage{mathtools} 6 | \usepackage{amssymb} 7 | \usepackage{tikz-cd} 8 | \usepackage{etoolbox} 9 | \usepackage[]{algorithm2e} 10 | \usepackage[section]{placeins} 11 | \usepackage{hyperref} 12 | \usepackage{cancel} 13 | 14 | \usepackage{scalerel} 15 | \usepackage{stackengine,wasysym} 16 | 17 | \newcommand\reallywidetilde[2]{\ThisStyle{% 18 | \setbox0=\hbox{$\SavedStyle#1$ }% 19 | \stackengine{-.1\LMpt}{$\SavedStyle#1$; #2}{% 20 | \stretchto{\scaleto{\SavedStyle\mkern.2mu\AC}{.5150\wd0}}{.6\ht0}% 21 | }{O}{c}{F}{T}{S}% 22 | }} 23 | 24 | 25 | %\usepackage{blindtext} 26 | 27 | %\usepackage[x11names]{xcolor} 28 | %\usepackage[textwidth=30mm]{todonotes} 29 | %\usepackage[dvipsnames,svgnames]{xcolor} % for color 30 | %\colorlet{MyBlue}{DodgerBlue!75!Black} 31 | %\colorlet{MyGreen}{DarkGreen!85!Black} 32 | %\newcommand{\GP}[1]{\todo[color=DodgerBlue!20!LightGray, 33 | %author=\textbf{GP}]{\small #1\\}} 34 | 35 | 36 | \newcommand{\entangled}[1]{\underset{#1}{\sim}} 37 | 38 | \usepackage{geometry} 39 | \geometry{ 40 | a4paper, 41 | total={170mm,257mm}, 42 | left=20mm, 43 | top=20mm, 44 | } 45 | 46 | \let\oldproofname=\proofname 47 | \renewcommand\proofname{\bf{\oldproofname}} 48 | \renewcommand\qedsymbol{$\blacksquare$} 49 | 50 | \theoremstyle{definition} 51 | \newtheorem{thm}{Theorem} 52 | \newtheorem{lemma}{Lemma} 53 | \newtheorem{defn}{Definition}[section] 54 | 55 | \newcommand{\notimplies}{% 56 | \mathrel{{\ooalign{\hidewidth$\not\phantom{=}$\hidewidth\cr$\implies$}}}} 57 | 58 | \newcommand{\cat}{ 59 | \mathbf 60 | } 61 | \newcommand{\domain}[1]{ 62 | \mathrm{dom}(#1) 63 | } 64 | \newcommand{\codomain}[1]{ 65 | \mathrm{cod}(#1) 66 | } 67 | \newcommand{\idarrow}[1][]{ 68 | \mathrm{1}_{#1} 69 | } 70 | \newcommand{\notdownharpoonright}{ 71 | \mathclap{\not}\makebox[\widthof{$\downharpoonright$\:\:}][c]{$\downharpoonright$} 72 | } 73 | 74 | \DeclareMathOperator*{\argmax}{arg\,max} 75 | 76 | \AtBeginEnvironment{quote}{\small} 77 | 78 | \setlength{\parindent}{0pt} 79 | \setlength{\parskip}{1em} 80 | \raggedbottom 81 | 82 | \graphicspath{{figures}} 83 | 84 | 85 | \begin{document} 86 | 87 | \title{Introducing the ``Minimal CBC Casper" Family of Consensus Protocols \\ \vspace{5mm} \small{DRAFT v1.0}} 88 | \author{Vlad Zamfir, Nate Rush, Aditya Asgaonkar, Georgios Piliouras \\ \\ Ethereum Research} 89 | \date{November 5, 2018} 90 | \maketitle 91 | 92 | \begin{abstract} 93 | CBC Casper is a family of ``correct-by-construction" consensus protocols that share the same proof of asynchronous, Byzantine-fault-tolerant consensus safety. We describe this family of protocols by defining their protocol states and protocol state transitions, and then we provide a proof of Byzantine-fault-tolerant consensus safety for the entire Minimal CBC Casper family of protocols. We give examples of members of this family of protocols, including a binary consensus protocol. ``Casper the Friendly Ghost", a blockchain consensus protocol, and a sharded blockchain consensus protocol. Each of these examples is ``correct-by-construction" because the way they are defined guarantees that they are part of this family of protocols, and therefore satisfy the consensus safety theorem. This draft is intended to be introductory and educational, it is not a complete description of a system that can be implemented exactly as specified. 94 | \end{abstract} 95 | 96 | \pagebreak 97 | \tableofcontents 98 | 99 | \pagebreak 100 | \section{Introduction} 101 | 102 | \subsection{Consensus Protocols} 103 | 104 | Consensus protocols are used by nodes in a distributed network to make consistent decisions out of possibly inconsistent alternative decisions. For example, in a binary consensus protocol a decision on ``1" is said to be inconsistent with a decision on ``0" and consistent with a decision on ``1". In a blockchain consensus protocol, a decision on one block is called ``inconsistent" with another when they are not in the same blockchain, and ``consistent" when they are in the same chain. 105 | 106 | More specifically, consensus protocols traditionally are said to provide two properties: 107 | \begin{itemize} 108 | \item \textbf{Safety}: It is not possible for nodes to make inconsistent decisions 109 | \item \textbf{Liveness}: Nodes eventually/inevitably make decisions 110 | \end{itemize} 111 | 112 | A consensus protocol is said to be ``synchronously safe" (or ``live in a synchronous network"), if its safety (or liveness) is guaranteed by an assumption about timing, or about the way that race conditions get resolved (e.g. all these messages will arrive before some timeout). It is called ``asynchronously safe" (or ``live in asynchrony") if its safety (or liveness) is guaranteed without assumptions about timing, or about the way that race conditions get resolved (with the exception that every message sent is eventually received). 113 | 114 | Fault tolerant consensus protocols have safety and/or liveness despite some number of \emph{faults}. Traditionally, faulty behaviour is either considered to be ``Crash Faulty", where nodes are faulty by virtue of not sending messages, or they are considered ``Byzantine", which means that they may exhibit arbitrary behaviour. There is a famous result known as ``FLP impossibility" \cite{Fischer_Lynch_Paterson_FLP_Impossibility_1985} that shows that it is impossible to have a deterministic consensus protocol that is safe and live in an asynchronous network, if there is one crash fault. 115 | 116 | More specifically, we use the following fault classification: 117 | 118 | \textbf{Liveness faults:} 119 | \begin{itemize} 120 | \item Crash fault: failing to send a message when expected 121 | \item Omission fault: failing to receive a message when expected 122 | \end{itemize} 123 | \textbf{Safety faults:} 124 | \begin{itemize} 125 | \item Invalid message fault: producing messages that cannot be produced by a protocol-following node 126 | \item Equivocation fault: producing valid messages in a way that could not have been produced by a \emph{single} execution of the protocol 127 | \end{itemize} 128 | 129 | They are named this way because liveness faults are indistinguishable from network latency (from any node in the distributed system that is not the faulty node itself), and because network latency (and therefore liveness faults) cannot cause protocol-following nodes to make inconsistent decisions in an asynchronously safe consensus protocol. We assumed that nodes can check the validity of messages, so if we insist that they do, then only equivocation faults will be able to cause consensus failure. 130 | 131 | In a non-trivial consensus protocol, protocol-following nodes following completely independent executions of the protocol can decide on inconsistent values. Equivocating nodes can (by definition) exclusively show different nodes messages from independent protocol executions, and as a result, a large enough number of equivocation faults is fundamentally enough to cause consensus failure in any consensus protocol. 132 | 133 | \subsection{About This Paper} 134 | 135 | This document specifies a family of asynchronously safe consensus protocols in terms of the protocol states (sets of messages) and protocol state transitions (the superset relation) that clients running the protocol will execute (by receiving messages from consensus forming nodes). Each member of the family satisfies a proof that if there are not more than some weight equivocations, then node decisions will be consistent. This number, the protocol's equivocation fault tolerance threshold, is given as a parameter of the CBC Casper family of protocols. The protocols will tolerate this equivocation fault tolerance threshold weight of Byzantine faults. 136 | 137 | Each member of the family is going to be identified by five ``parameters". Four of these parameters can be given before the protocol specification, but one (``the estimator") must initially be left undefined because it is a function of the (initially undefined) protocol states. The specification of the family of protocols is a partial specification of any member of the family, because the parameters need to be defined in order for a consensus protocol to be specified. It is possible to choose the parameters in a way that corresponds to a trivial consensus protocol, so we will give some non-trivial example protocols by giving example parameters. 138 | 139 | Note that this work does not make any synchrony assumptions, nor does it discuss liveness. It doesn't say anything about when validators send or receive messages. It doesn't address validator rotation, incentive mechanisms, proof-of-stake, light clients, scalability, or message source authentication. The consensus protocols specified here therefore should not be considered completely specified even after the parameters are specified. 140 | 141 | \subsection{Prerequisite Notation} 142 | \begin{center} 143 | \fbox{ 144 | \parbox{\textwidth-4em}{ 145 | \begin{align*} 146 | &\textbf{Notation} &&\textbf{Description} \\ 147 | &\neg p,~ p \land q,~ p \lor q &&\text{boolean negation, ``and", ``or"} \\ 148 | &p \implies q, ~ p \iff q &&\text{boolean implication and equivalence} \\ 149 | &X = \{x_1, x_2, \dots, x_n\} &&\text{set notation} \\ 150 | &\{\} = \emptyset &&\text{the empty set} \\ 151 | & X \cup Y,~ X \cap Y,~ X \setminus Y &&\text{set union, intersection, difference} \\ 152 | &X \subseteq Y, X \subset Y &&\text{improper subset and proper subset} \\ 153 | &X \times Y &&\text{Cartesian product} \\ 154 | &x \in X &&\text{set membership} \\ 155 | &\forall x \in X, ~\exists y \in Y &&\text{universal and existential quantifiers} \\ 156 | &Y^{X} &&\text{the set of maps from $X$ to $Y$} \\ 157 | &\{y \in Y : \exists x \in X, f(x) = y\} &&\text{set builder notation} \\ 158 | &\mathbb{N},~ \mathbb{Z},~ \mathbb{R} &&\text{Natural numbers, integers, real numbers} \\ 159 | &\sum_{x \in X} W(x), &&\text{``Sigma" sum notation} \\ 160 | &\lambda x. f(x, y) &&\text{lambda (anonymous) function creation} 161 | \end{align*} 162 | } 163 | } 164 | \end{center} 165 | 166 | 167 | \subsection{Acknowledgements} 168 | 169 | We would like to thank Leslie Lamport and other pre-blockchain consensus protocol researchers for founding the field that left us with excellent definitions and some interesting consensus protocols, Satoshi Nakamoto for Nakamoto (``Proof-of-Work") consensus\cite{nakamoto}, as it served as an excellent introduction to Byzantine fault tolerant consensus and because its ``forking" behaviour directly led to this work, and Greg Meredith for work on the definition of the protocol message data structure and for the introduction to the ``correct-by-construction" methodology. We would finally like to thank Vitalik Buterin for his continued support, collaboration, and mentorship since the very early stages of this research, over three years ago. 170 | 171 | \pagebreak 172 | \section{Description of CBC Casper} 173 | 174 | \subsection{CBC Casper ``Parameters"} 175 | 176 | Our first parameter is a set of names that will label the senders of protocol messages. The senders are understood to be the consensus-forming nodes, called ``validators": 177 | 178 | \begin{defn}[Validator names] 179 | A non-empty set: 180 | $$ 181 | \mathcal{V} 182 | $$ 183 | \end{defn} 184 | 185 | Without loss of generality (and in preparation for proof-of-stake), we assign a weight to each validator: 186 | 187 | \begin{defn}[Validator weights] 188 | A function: 189 | $$ 190 | \mathcal{W}: \mathcal{V} \to \mathbb{R}_+ 191 | $$ 192 | \end{defn} 193 | 194 | The CBC Casper protocol states are parametric in a Byzantine-fault-tolerance threshold: 195 | 196 | \begin{defn}[Byzantine-fault-tolerance threshold] 197 | A non-negative real number, strictly smaller than the total validator weights 198 | $$0 \leq t < \sum_{v \in \mathcal{V}} \mathcal{W}(v)$$ 199 | \end{defn} 200 | 201 | The protocols will be guaranteed to have consensus safety tolerating up to ``$t$ Byzantine faults", \emph{measured by weight}. 202 | 203 | Different protocols in the CBC Casper family can make decisions regarding different values: 204 | 205 | \begin{defn}[Consensus values] 206 | A multi-element set: 207 | $$ 208 | \mathcal{C} 209 | $$ 210 | \end{defn} 211 | 212 | In a binary consensus protocol, $\mathcal{C} = \{0,1\}$, while in a blockchain consensus protocol, $\mathcal{C}$ is the set of all possible blockchains. 213 | 214 | The final parameter, called ``the estimator", relates CBC Casper protocol states to sets of consensus values (subsets of $\mathcal{C}$). To give the function signature of this parameter we need to define the CBC Casper protocol states, $\Sigma$. However, we will leave this for the protocol definition section, and for now simply write: 215 | 216 | \begin{defn}[Estimator] 217 | A function 218 | $$ 219 | \mathcal{E}: \Sigma \to \mathcal{P}(\mathcal{C})\setminus\{\emptyset\} 220 | $$ 221 | \end{defn} 222 | 223 | Where $\mathcal{P}$ is the powerset function. When the estimator returns a multi-element set, validators will have an opportunity to choose non-deterministically between consensus values. Because the domain of the estimator has not yet been defined, it is not quite proper for us to ask for the estimator as a parameter. However, for ease of presentation we will assume that we have the estimator as a parameter. 224 | 225 | Minimal CBC Casper protocol states will therefore be determined by the choice of these parameters: 226 | 227 | \begin{itemize} 228 | \item Validator names $\mathcal{V}$, 229 | \item Validator weights $\mathcal{W}$, 230 | \item Fault tolerance threshold $t$, 231 | \item Consensus values $\mathcal{C}$, and 232 | \item Estimator $\mathcal{E}$ 233 | \end{itemize} 234 | 235 | \pagebreak 236 | \subsection{Protocol Definition} 237 | 238 | We will define protocol states ($\Sigma$) as \emph{certain} sets of messages, and messages ($M$) as \emph{certain} triples of the form (consensus value, validator name, protocol state). Our target is therefore something that satisfies the following formulas: 239 | 240 | \begin{align} 241 | \Sigma &\subset \mathcal{P}_{finite}(M) \\ 242 | M &\subset \mathcal{C} \times \mathcal{V} \times \Sigma 243 | \end{align} 244 | 245 | We will call the consensus value the ``estimate" of a message, the validator name the ``sender", and the protocol state the ``justification", and define these corresponding convenience functions: 246 | 247 | \begin{defn}[Estimate, Sender, Justification] 248 | \begin{align} 249 | Estimate&:M \to \mathcal{C} \\ 250 | Sender&:M \to \mathcal{V} \\ 251 | Justification&:M \to \Sigma \\ 252 | Estimate((c, v, \sigma)) &:= c \\ 253 | Sender((c, v, \sigma)) &:= v \\ 254 | Justification((c, v, \sigma)) &:= \sigma 255 | \end{align} 256 | \end{defn} 257 | 258 | We can construct finite protocol states that satisfy these equations by using the empty set of messages as the base case: 259 | 260 | \begin{defn}[Preliminary protocol states, $\Sigma$, protocol messages $M$] 261 | \begin{align} 262 | \Sigma^0& := \{\emptyset\} \\ 263 | M^n& := \{ m \in \mathcal{C} \times \mathcal{V} \times \Sigma^n: Estimate(m) \in \mathcal{E}(Justification(m))\}\\ 264 | \Sigma^n& := \{ \sigma \in \mathcal{P}_{finite}(M^{n-1}) : m \in \sigma \implies Justification(m) \subseteq \sigma \} ~ ~ \text{ for $n > 0$ } \\ 265 | M& := \bigcup_{i = 0}^{\infty} M^i \\ 266 | \Sigma& := \bigcup_{i = 0}^{\infty} \Sigma^i 267 | \end{align} 268 | \end{defn} 269 | 270 | The type signature of the estimator is $\mathcal{E} : \Sigma \to \mathcal{P}(\mathcal{C}) \setminus \{\emptyset\}$, causing possible concern due to our application of $\mathcal{E}$ to $Justification(m) \in \Sigma^n \neq \Sigma$. However we note that $\Sigma^n \subset \Sigma$, meaning that $\mathcal{E}$ is defined over $\Sigma^n$. 271 | 272 | Note that we explicitly restricted protocol messages to only have consensus values from the estimator, allowing validators to make a choice between values of the consensus when the the estimator returns a multi-element set (but not otherwise). 273 | 274 | We also restricted the definition of protocol states so that we could have the following definition of protocol state transitions: 275 | 276 | \begin{defn}[Protocol state transitions $\to$] 277 | \begin{align} 278 | \to &: \Sigma \times \Sigma \to \{True,False\} \\ 279 | &\sigma_1 \to \sigma_2 :\Leftrightarrow \hspace{1mm} \sigma_1 \subseteq \sigma_2 280 | \end{align} 281 | \end{defn} 282 | 283 | 284 | We will write this as $\sigma \rightarrow \sigma'$ and we will write $\sigma \nrightarrow \sigma'$ when there is not a state transition from $\sigma$ to $\sigma'$. 285 | 286 | 287 | We now pivot towards defining the protocol states for the CBC Casper protocol, with fault tolerance threshold $t$, $\Sigma_t \subset \Sigma$. But first, we need to talk about equivocation (a kind of Byzantine fault). 288 | 289 | Equivocation faults are a Byzantine behaviour that is fundamentally enough to cause consensus failure in any consensus protocol. CBC Casper protocols are guaranteed to be safe as long as not more than $t$ weight of validators are equivocating (and therefore Byzantine). 290 | 291 | \begin{defn}[Equivocating messages] 292 | \begin{align} 293 | \cdot \perp \cdot &: M \times M \to \{True,False\}\\ 294 | m_1 \perp m_2 &:\Leftrightarrow ~ Sender(m_1) = Sender(m_2) \land m_1 \neq m_2 \\ 295 | &\land m_1 \notin Justification(m_2) \land m_2 \notin Justification(m1) 296 | \end{align} 297 | \end{defn} 298 | 299 | Equivocating messages are distinct messages from the same validator that do not include each other in their justifications. 300 | 301 | The equivocating validators in a protocol state are simply the validators who have equivocating messages in that state: 302 | 303 | \begin{defn}[Equivocating validators] 304 | \begin{align} 305 | E: \Sigma &\to \mathcal{P}(\mathcal{V}) \\ 306 | E(\sigma) &:= \{v \in \mathcal{V} : \exists m_1 \in \sigma, \exists m_2 \in \sigma , \hspace{1mm} m_1 \perp m_2 \hspace{1mm} \land \hspace{1mm} Sender(m_1) = v \} 307 | \end{align} 308 | \end{defn} 309 | 310 | Equivocation corresponds to behaviour that is not ``single threaded". We will eventually see a lemma showing that non-equivocating validators have at most one latest message. 311 | 312 | Instead of considering the number of equivocations, we measure equivocations by weight: 313 | 314 | \begin{defn}[Equivocation fault weight] 315 | \begin{align} 316 | F: \Sigma &\to \mathbb{R}_+ \\ 317 | F(\sigma) &:= \sum_{v \in E(\sigma)} \mathcal{W}(v) 318 | \end{align} 319 | \end{defn} 320 | 321 | Note that $F$ is a monotonic function (i.e. $\sigma_1 \subseteq \sigma_2 \implies F(\sigma_1) \leq F(\sigma_2)$). 322 | 323 | The CBC Casper protocol states will be parametric in an equivocation fault tolerance threshold $t$, and will use the following protocol states: 324 | 325 | \begin{defn}[Protocol states (with equivocation fault tolerance t)] 326 | $$ 327 | \Sigma_t = \{\sigma \in \Sigma : F(\sigma) \leq t\} 328 | $$ 329 | \end{defn} 330 | 331 | We think of protocol-following nodes as existing in these protocol states ($\Sigma_t$), and following the protocol state transitions ($\to$) to get from one state to another. If a node at state $\sigma \in \Sigma_t$ receives messages $m$ such that $\sigma \cup \{m\} \in \Sigma$, then they will transition to state $\sigma \cup \{m\}$, if it doesn't expose the node to too many equivocation faults (i.e., as long as $F(\sigma \cup \{m\}) \leq t$). 332 | 333 | We are now finished with the protocol definition and are ready to prove consensus safety for the family of protocols that satisfy this definition (in the context of less than $t$ equivocations (by weight)). 334 | 335 | 336 | \pagebreak 337 | \section{Safety Proof} 338 | 339 | Our goal is to provide a way for nodes to make consistent decisions even if they receive different messages, as long as there are less than $t$ equivocation faults in their protocol states. We do this in two steps, first by guaranteeing that nodes will have common future protocol states (as long as there are less than $t$ equivocation faults \emph{in the union of their protocol states}), and then by showing that their decisions on properties of protocol states will be consistent (if they share common future states, which they will if there are not too many faults). Finally, we will show how this result can be leveraged to guarantee the consistency of decisions on properties of consensus values. 340 | 341 | \subsection{Guaranteeing Common Futures} 342 | 343 | We will define the common futures of protocol states in terms of the intersection of their ``futures cones": 344 | 345 | \begin{defn}[Futures cone in $\Sigma_t$] 346 | \begin{align} 347 | Futures_t&: \Sigma_t \to \mathcal{P}( \Sigma_t) \\ 348 | Futures_t(\sigma) &:= \{ \sigma' \in \Sigma_t : \sigma \to \sigma' \} 349 | \end{align} 350 | \end{defn} 351 | 352 | Note that the futures function is monotonic in protocol state transitions, meaning that the futures cone ``shrinks" during protocol execution: 353 | 354 | \begin{lemma}[Monotonic futures] 355 | $\forall \sigma \in \Sigma_t$, $\forall \sigma' \in \Sigma_t$, 356 | $$ 357 | \sigma' \in Futures_t(\sigma) \iff Futures_t(\sigma') \subseteq Futures_t(\sigma) 358 | $$ 359 | \end{lemma} 360 | 361 | \begin{proof} 362 | (Forwards direction) 363 | \begin{align} 364 | \sigma' \in Futures_t(\sigma)\iff &\sigma \to \sigma' \\ 365 | \iff &\sigma \to \sigma' \land \forall \sigma''' \in Futures_t(\sigma'), \sigma' \to \sigma''' \\ 366 | \iff &\sigma \to \sigma' \land \forall \sigma''' \in Futures_t(\sigma'), \sigma' \to \sigma''' \land \sigma \to \sigma''' \\ 367 | \implies &\forall \sigma''' \in Futures_t(\sigma'), \sigma' \to \sigma''' \land \sigma \to \sigma''' \\ 368 | \implies &\forall \sigma''' \in Futures_t(\sigma'), \sigma \to \sigma''' \\ 369 | \iff &\forall \sigma''' \in Futures_t(\sigma'), \sigma''' \in Futures_t(\sigma) \\ 370 | \iff &Futures_t(\sigma') \subseteq Futures_t(\sigma) 371 | \end{align} 372 | (Backwards direction) 373 | \begin{align} 374 | Futures_t(\sigma') \subseteq Futures_t(\sigma) &\iff \forall \sigma'' \in Futures_t(\sigma'), \sigma'' \in Futures_t(\sigma)\\ 375 | &\iff \forall \sigma'' \in Futures_t(\sigma'), \sigma'' \in Futures_t(\sigma) \land \sigma' \in Futures_t(\sigma')\\ 376 | &\implies \sigma' \in Futures_t(\sigma) 377 | \end{align} 378 | \end{proof} 379 | 380 | %add footnote to say that the other direction, s1~s1 => F(s1s2) \leq t 381 | We will now present our first key theorem, which guarantees that pairs of nodes have common future states if not more than $t$ fault weight is observed in the union of their states: 382 | 383 | \begin{thm}[2-party common futures] 384 | $\forall \sigma_1 \in \Sigma_t$, $\forall \sigma_2 \in \Sigma_t$, 385 | $$ 386 | F(\sigma_1 \cup \sigma_2) \leq t \implies Futures_t(\sigma_1) \cap Futures_t(\sigma_2) \neq \emptyset 387 | $$ 388 | \end{thm} 389 | 390 | \begin{proof} 391 | \begin{align} 392 | F(\sigma_1 \cup \sigma_2) \leq t &\iff \sigma_1 \cup \sigma_2 \in \Sigma_t \\ 393 | &\iff \sigma_1 \cup \sigma_2 \in \Sigma_t \land\sigma_1 \to \sigma_1 \cup \sigma_2 \land \sigma_2 \to \sigma_1 \cup \sigma_2 \\ 394 | &\iff \sigma_1 \cup \sigma_2 \in \Sigma_t \land \sigma_1 \to \sigma_1 \cup \sigma_2 \land \sigma_1 \cup \sigma_2 \in \Sigma_t \land \sigma_2 \to \sigma_1 \cup \sigma_2 \\ 395 | &\iff \sigma_1 \cup \sigma_2 \in Futures_t(\sigma_1) \land \sigma_1 \cup \sigma_2 \in Futures_t(\sigma_2) \\ 396 | &\iff \sigma_1 \cup \sigma_2 \in Futures_t(\sigma_1) \cap Futures_t(\sigma_2) \\ 397 | &\implies Futures_t(\sigma_1) \cap Futures_t(\sigma_2) \neq \emptyset \\ 398 | \end{align} 399 | \end{proof} 400 | 401 | Note the analogous guarantee that $n$ nodes have a common future if there aren't too many faults in the union of their states: 402 | 403 | \begin{thm}[$n$-party common futures] 404 | \label{thm:nparty_bft_common_futures} 405 | $\forall \sigma_i \in \Sigma_t$, 406 | $$ 407 | F(\bigcup_{i=1}^n \sigma_i) \leq t \implies \bigcap_{i=1}^n Futures_t(\sigma_i) \neq \emptyset 408 | $$ 409 | \end{thm} 410 | 411 | \begin{proof} 412 | Similar to proof of the 2-argument version. 413 | \end{proof} 414 | 415 | The theorems above guarantee that protocol-following nodes have a common future state if the validators that are equivocating in the union of their states have no more than $t$ weight. Therefore, if Byzantine (\emph{and equivocating}) validators have no more than $t$ weight, all protocol-following nodes will have a common future state. 416 | 417 | We will use this result to ensure the consistency of decisions made by protocol-following nodes, guaranteeing the consensus safety of CBC Casper consensus protocols. 418 | 419 | \subsection{Guaranteeing Consistent Decisions} 420 | 421 | In this section, we show that if nodes have a common future state, then all of the invariant properties of their protocol states are consistent. We guarantee consensus safety by insisting that nodes have decided on the invariant properties of their protocol states. We leverage the consistency of decisions on properties of protocol states to guarantee the consistency of decisions on properties of consensus values. 422 | 423 | \subsubsection{Guaranteeing Consistent Decisions on Properties of Protocol States} 424 | 425 | Before we can formally state our consensus safety theorems, we need to define some preliminary notions. First, we consider properties of protocol states to be maps from protocol states to $True$ or $False$: 426 | 427 | \begin{defn}[Properties of protocol states] 428 | $$ 429 | P_\Sigma = \{True, False\}^\Sigma %\text{functions $f$ with signature } f : \Sigma \to \{True, False\} 430 | $$ 431 | \end{defn} 432 | 433 | We say that a property of a protocol state is called ``decided" from some protocol state if it holds for all future protocol states: 434 | 435 | \begin{defn}[Decided properties of protocol states] 436 | \begin{align} 437 | Decided_{\Sigma, t}&: P_\Sigma \times \Sigma \to \{True,False\} \\ 438 | Decided_{\Sigma, t}(p, \sigma) &:\Leftrightarrow \forall \sigma' \in Futures_t(\sigma), p(\sigma') 439 | \end{align} 440 | \end{defn} 441 | 442 | We will now prepare lemmas that we will use to prove consensus safety. 443 | 444 | Our first lemma says that if a node is decided on a property at some state, then it will be decided on this property at its future protocol states: 445 | 446 | \begin{lemma}[Forward consistency] 447 | \label{lem:forw_safe} $\forall \sigma \in \Sigma_t$, $\forall \sigma' \in \Sigma_t$, $\forall p \in P_\Sigma$, 448 | $$ 449 | \sigma' \in Futures_t(\sigma) \implies (Decided_{\Sigma, t}(p,\sigma) \implies Decided_{\Sigma, t}(p,\sigma')) 450 | $$ 451 | \end{lemma} 452 | 453 | \begin{proof} 454 | \begin{align} 455 | &\sigma' \in Futures_t(\sigma) \land Decided_{\Sigma, t}(p,\sigma) \\ 456 | \iff & Futures_t(\sigma') \subseteq Futures_t(\sigma) \land Decided_{\Sigma, t}(p,\sigma) \\ 457 | \iff & Futures_t(\sigma') \subseteq Futures_t(\sigma) \land \forall \sigma'' \in Futures_t(\sigma), p(\sigma'') \\ 458 | \implies &\forall \sigma'' \in Futures_t(\sigma'), p(\sigma'')\\ 459 | \iff &Decided_{\Sigma, t}(p, \sigma') 460 | \end{align} 461 | So now we have 462 | \begin{align} 463 | &\sigma' \in Futures_t(\sigma) \land Decided_{\Sigma, t}(p,\sigma) \implies Decided_{\Sigma, t}(p, \sigma')\\ 464 | \implies &\sigma' \in Futures_t(\sigma) \implies (Decided_{\Sigma, t}(p,\sigma) \implies Decided_{\Sigma, t}(p, \sigma'))\\ 465 | \end{align} 466 | \end{proof} 467 | 468 | 469 | \iffalse 470 | \begin{lemma}[Current consistency] 471 | $\forall p \in P_\Sigma$, 472 | $$ 473 | Decided_{\Sigma, t}(p,\sigma) \implies \neg Decided_{\Sigma, t}(\neg p, \sigma) 474 | $$ 475 | \end{lemma} 476 | 477 | \begin{proof} 478 | \begin{align} 479 | Decided_{\Sigma, t}(p,\sigma) &\implies \forall \sigma' \in Futures_t(\sigma), p(\sigma')\\ 480 | &\implies \exists \sigma' \in Futures_t(\sigma), p(\sigma')\\ 481 | &\implies \neg \forall \sigma' \in Futures_t(\sigma), \neg p(\sigma')\\ 482 | &\implies \neg Decided_{\Sigma, t}(\neg p, \sigma) 483 | \end{align} 484 | \end{proof} 485 | \fi 486 | 487 | Our second lemma says that if a node has a decided property at some state, then the negation of that property must not have been decided at any possible past state. 488 | 489 | \begin{lemma}[Backwards consistency] 490 | \label{lem:backw_safe} 491 | $\forall \sigma \in \Sigma_t, \forall \sigma' \in \Sigma_t, \forall p \in P_\Sigma$, 492 | $$ 493 | \sigma' \in Futures_t(\sigma) \implies (Decided_{\Sigma, t}(p,\sigma') \implies \neg Decided_{\Sigma, t}(\neg p,\sigma)) 494 | $$ 495 | \end{lemma} 496 | 497 | Where $\neg$ denotes negation and is defined as expected. %($\neg:\{True,False\}\to\{True,False\}$ with $\neg True = False$ and $\neg False = True$) 498 | 499 | \begin{proof} 500 | \begin{align} 501 | &\sigma' \in Futures_t(\sigma) \land Decided_{\Sigma, t}(p,\sigma') \\ 502 | \iff &Futures_t(\sigma') \subseteq Futures_t(\sigma) \land Decided_{\Sigma, t}(p, \sigma') \\ 503 | \iff &Futures_t(\sigma') \subseteq Futures_t(\sigma) \land \forall \sigma'' \in Futures_t(\sigma'), p(\sigma'') \\ 504 | \implies &Futures_t(\sigma') \subseteq Futures_t(\sigma) \land \exists \sigma'' \in Futures_t(\sigma), p(\sigma'') \\ 505 | \implies &\exists \sigma'' \in Futures_t(\sigma), p(\sigma'') \\ 506 | \iff &\neg \forall \sigma'' \in Futures_t(\sigma), \neg p(\sigma'') \\ 507 | \iff &\neg Decided_{\Sigma, t}(\neg p, \sigma) 508 | \end{align} 509 | So now we have 510 | \begin{align} 511 | &\sigma' \in Futures_t(\sigma) \land Decided_{\Sigma, t}(p,\sigma') \implies \neg Decided_{\Sigma, t}(\neg p, \sigma)\\ 512 | \implies &\sigma' \in Futures_t(\sigma) \implies (Decided_{\Sigma, t}(p,\sigma') \implies \neg Decided_{\Sigma, t}(\neg p, \sigma)) \\ 513 | \end{align} 514 | \end{proof} 515 | 516 | We will now use these two lemmas to prove two-party consensus safety. We show this result before showing $n$-party consensus safety as it is considerably more accessible. Because nodes only decide on properties of protocol states, the only way two nodes can make inconsistent decisions is if one node is decided on a property $p$, and the other is decided on its negation $\neg p$. Our two-party consensus safety theorem therefore states that two nodes don't decide on $p$ and $\neg p$ if there aren't more than $t$ faults: 517 | 518 | \begin{thm}[Two-party consensus safety] 519 | \label{thm:2party_consensus_safety} 520 | $\forall \sigma_1 \in \Sigma_t, \forall \sigma_2 \in \Sigma_t, \forall p \in P_\Sigma$, 521 | \begin{align} 522 | F(\sigma_1 \cup \sigma_2) \leq t \implies \neg (Decided_{\Sigma, t}(p,\sigma_1) \land Decided_{\Sigma, t}(\neg p, \sigma_2)) 523 | \end{align} 524 | \end{thm} 525 | 526 | \begin{proof} 527 | \begin{align} 528 | F(\sigma_1\cup\sigma_2) \leq t &\implies Futures_t(\sigma_1) \cap Futures_t(\sigma_2) \neq \emptyset \\ 529 | &\iff \exists \sigma \in Futures_t(\sigma_1) \cap Futures_t(\sigma_2) \\ 530 | &\iff \exists \sigma \in \Sigma_t, \sigma \in Futures_t(\sigma_1) \land \sigma \in Futures_t(\sigma_2)\\ 531 | &\implies \exists \sigma \in \Sigma_t, (Decided_{\Sigma, t}(p,\sigma_1) \implies Decided_{\Sigma, t}(p,\sigma)) \land (Decided_{\Sigma, t}(p,\sigma) \implies \neg Decided_{\Sigma, t}(\neg p,\sigma_2)) \\ 532 | &\implies Decided_{\Sigma, t}(p,\sigma_1) \implies \neg Decided_{\Sigma, t}(\neg p, \sigma_2) \\ 533 | &\iff \neg Decided_{\Sigma, t}(p,\sigma_1) \lor \neg Decided_{\Sigma, t}(\neg p, \sigma_2) \\ 534 | &\iff \neg (Decided_{\Sigma, t}(p,\sigma_1) \land Decided_{\Sigma, t}(\neg p, \sigma_2)) 535 | \end{align} 536 | \end{proof} 537 | 538 | Note the contrapositive of this theorem, which shows that the existence of nodes at two states with inconsistent decisions implies that there are more than $t$ weight of validators equivocating: 539 | 540 | $$ 541 | \exists p \in P_\Sigma,~ Decided_{\Sigma, t}(p,\sigma_1) \land Decided_{\Sigma, t}(\neg p, \sigma_2) \implies F(\sigma_1 \cup \sigma_2) > t 542 | $$ 543 | 544 | Unfortunately, the two-party consensus safety result is not sufficient to guarantee the consistency of decisions made by more than 2 parties. To see this, consider a triple of properties $p$, $q$, $r$ such that $p~ \land~ q \implies \neg r$. If three nodes decide on $p$, $q$ and $r$ respectively, then they will have made inconsistent decisions, although they may be consistent pairwise. We therefore need to understand inconsistent decisions in a more general way than we considered for the two-party consensus safety result, where looking at properties and their negations was sufficient. 545 | 546 | We will say that properties are ``inconsistent'' if, for all protocol states, their conjunction is false: 547 | 548 | \begin{defn}[Inconsistency of properties of protocol states] 549 | $$ Inconsistent_\Sigma : \mathcal{P}(P_\Sigma) \to \{True, False\}$$ 550 | $$ Inconsistent_\Sigma(Q): \Leftrightarrow \forall \sigma \in \Sigma, \bigwedge_{q \in Q} q(\sigma) = False $$ 551 | \end{defn} 552 | 553 | Then we will say that properties are ``consistent" if they are not inconsistent: 554 | \begin{align} 555 | \neg Inconsistent_\Sigma(Q) \iff \neg (&\forall \sigma \in \Sigma, \bigwedge_{q \in Q} q(\sigma) = False) \\ 556 | \iff &\exists \sigma \in \Sigma, \bigwedge_{q \in Q} q(\sigma) = True \\ 557 | \iff &\exists \sigma \in \Sigma, \forall q \in Q, q(\sigma) 558 | \end{align} 559 | 560 | Which is to say that a set of properties is consistent if there is at least one protocol state that satisifies each of them: 561 | 562 | \begin{defn}[Consistency of properties of protocol states] 563 | $$ Consistent_\Sigma : \mathcal{P}(P_\Sigma) \to \{True, False\}$$ 564 | $$ Consistent_\Sigma(Q): \Leftrightarrow \exists \sigma \in \Sigma, \forall q \in Q, ~ q(\sigma)$$ 565 | \end{defn} 566 | 567 | The $n$-party consensus safety result will show the consistency of \emph{all} the decided properties in \emph{any} of the states of our $n$ nodes, if there are not more than $t$ equivocation faults by weight. So, we need to define a function that collects all the decisions from protocol states: 568 | 569 | \begin{defn}[Decisions on properties of protocol states] 570 | $$ Decisions_{\Sigma,t} : \Sigma \to \mathcal{P}(P_\Sigma)$$ 571 | $$ Decisions_{\Sigma,t}(\sigma)= \{ p \in P_\Sigma: Decided_{\Sigma, t}(p,\sigma) \}.$$ 572 | \end{defn} 573 | 574 | Now, we state the $n$-party consensus safety result, that the decided properties are consistent (if there aren't too many faults): 575 | 576 | \begin{thm}[$n$-party consensus safety for properties of protocol states] 577 | \label{thm:nparty_consensus_safety} 578 | $\forall \sigma_i \in \Sigma_t$, 579 | $$ 580 | F(\bigcup_{i=1}^n \sigma_i) \leq t \implies Consistent_\Sigma(\bigcup_{i=1}^n Decisions_{\Sigma,t}(\sigma_i)) 581 | $$ 582 | \end{thm} 583 | 584 | \begin{proof} 585 | \begin{align} 586 | F(\bigcup_{i=1}^n \sigma_i) \leq t &\implies \bigcap_{i=1}^n Futures_t(\sigma_i) \neq \emptyset \\ 587 | &\iff \exists \sigma \in \Sigma_t, \sigma \in \bigcap_{i = 1}^n Futures_t(\sigma_i) \\ 588 | &\iff \exists \sigma \in \Sigma_t, \bigwedge_{i = 1}^n \sigma \in Futures_t(\sigma_i) \\ 589 | &\iff \exists \sigma \in \Sigma_t, \bigwedge_{i = 1}^n \sigma \in Futures_t(\sigma_i) \\ 590 | &\land \bigwedge_{j = 1}^n \sigma \in Futures_t(\sigma_j) \implies (\forall p \in P_\Sigma, Decided_{\Sigma, t}(p,\sigma_j) \implies Decided_{\Sigma, t}(p, \sigma)) \\ 591 | &\implies \exists \sigma \in \Sigma_t,\bigwedge_{i = 1}^n \forall p \in P_\Sigma, Decided_{\Sigma, t}(p,\sigma_i) \implies Decided_{\Sigma, t}(p, \sigma) \\ 592 | &\implies \exists \sigma \in \Sigma_t,\bigwedge_{i = 1}^n \forall p \in Decisions_{\Sigma,t}(\sigma_i), Decided_{\Sigma, t}(p,\sigma_i) \implies Decided_{\Sigma, t}(p, \sigma)\\ 593 | &\iff \exists \sigma \in \Sigma_t, \bigwedge_{i = 1}^n \forall p \in Decisions_{\Sigma,t}(\sigma_i), Decided_{\Sigma, t}(p, \sigma)\\ 594 | &\iff \exists \sigma \in \Sigma_t, \forall p \in \bigcup_{i=1}^n Decisions_{\Sigma,t}(\sigma_i), Decided_{\Sigma, t}(p, \sigma)\\ 595 | &\implies \exists \sigma \in \Sigma_t, \forall p \in \bigcup_{i=1}^n Decisions_{\Sigma,t}(\sigma_i), p(\sigma)\\ 596 | %&\implies \exists \sigma \in \Sigma, \forall p \in Decisions_{\Sigma,t}(\sigma_i), p(\sigma)\\ 597 | &\iff Consistent_\Sigma(\bigcup_{i=1}^n Decisions_{\Sigma,t}(\sigma_i)) 598 | \end{align} 599 | \end{proof} 600 | 601 | 602 | \iffalse 603 | \begin{proof} 604 | Let %$$\sigma= \cup_i \sigma_i \in \cap_i Futures_t(\sigma_i)$$ 605 | $ \sigma=\bigcup_{i=1}^n \sigma_i \in \bigcap_{i=1}^n Futures_t(\sigma_i)$. For any $i$, for any $p \in Decisions_{\Sigma,t}(\sigma_i)$, we have that $Decided_{\Sigma, t}(p,\sigma)$ from lemma \ref{lem:forw_safe}. 606 | We have that $Decisions_{\Sigma,t}(\sigma_1,\sigma_2,\dots,\sigma_n)\subseteq Decisions_{\Sigma,t}(\sigma)$. 607 | Hence $\mathcal{E}(\sigma)$ is a set of consensus values that satisfies all properties $p \in Decisions_{\Sigma,t}(\sigma_1,\sigma_2,\dots,\sigma_n)$. Therefore $\exists c \in \mathcal{C}, \forall p \in Decisions_{\Sigma,t}(\sigma_1,\sigma_2,\dots,\sigma_n)~ p(c)$. 608 | \end{proof} 609 | \fi 610 | 611 | Note the contrapositive, that the existence of inconsistent decisions means that there must be more than $t$ weight equivocating: 612 | $$ 613 | \neg Consistent_\Sigma(\bigcup_{i=1}^n Decisions_{\Sigma,t}(\sigma_i)) \implies F(\bigcup_{i=1}^n \sigma_i) > t 614 | $$ 615 | 616 | This concludes the consensus safety proof for decisions on properties of protocol states. We will now show how we can leverage this consensus safety theorem and the estimator to allow nodes to make consistent decisions on properties of consensus values. 617 | 618 | \subsubsection{Guaranteeing Consistent Decisions on Properties of Consensus Values} 619 | 620 | We will define properties of consensus values as the maps from consensus values to $True$ or $False$: 621 | 622 | \begin{defn}[Properties of consensus values] 623 | $$ 624 | P_{\mathcal{C}} = \{ f \in \{True, False\}^\mathcal{C} \} 625 | $$ 626 | \end{defn} 627 | 628 | For every property of consensus values there is a naturally corresponding property of protocol states, which is satisfied (by a protocol state) if the property of consensus holds for all values of the estimator (at that protocol state): 629 | 630 | \begin{defn}[H, naturally corresponding property of protocol states] 631 | \begin{align} 632 | H&: P_{\mathcal{C}} \to P_\Sigma \\ 633 | H(p) &:\Leftrightarrow \lambda \sigma . \forall c \in \mathcal{E}(\sigma), p(c) 634 | \end{align} 635 | \end{defn} 636 | 637 | For example, if we have an estimator for a binary consensus protocol, which has function signature $\mathcal{E}: \Sigma \to \mathcal{P}(\{0,1\})\setminus \{\emptyset\}$, and the property of consensus values $p \in P_{\{0, 1\}}$ with $p(0) = True$ and $p(1) = False$, then $H(p)$ is defined to be satisifed by a protocol state $\sigma$ if $\mathcal{E}(\sigma) = \{0\}$, but not if $\mathcal{E}(\sigma) = \{1\}$ or $\mathcal{E}(\sigma) = \{0, 1\}$. 638 | 639 | We will define the consistency of properties of consensus values in the same way that we defined consistency of properties of protocol states, namely that they are consistent if there is a value of the consensus that satisifes all of them: 640 | 641 | \begin{defn}[Consistency of properties of the consensus] 642 | $$Consistent_{\mathcal{C}} : \mathcal{P}(P_{\mathcal{C}}) \to \{True, False\}$$ 643 | $$Consistent_{\mathcal{C}}(Q): \Leftrightarrow \exists c \in \mathcal{C}, \forall q \in Q, ~ q(c)$$ 644 | \end{defn} 645 | 646 | We will now show an important lemma, that if properties of protocol states that correspond to properties of consensus values are consistent, then these properties of consensus values are also consistent: 647 | 648 | \begin{lemma} 649 | $\forall p_i \in P_{\mathcal{C}}$, 650 | $$ 651 | Consistent_\Sigma(\{H(p_1), H(p_2),\dots,H(p_n)\}) \implies Consistent_{\mathcal{C}}(\{p_1,p_2,\dots,p_n\}) 652 | $$ 653 | \end{lemma} 654 | 655 | \begin{proof} 656 | \begin{align} 657 | &Consistent_\Sigma(\{H(p_1), H(p_2), \dots, H(p_n)\}) \\ 658 | \iff &\exists \sigma \in \Sigma, \forall i \in \{1,2,\dots,n\}, H(p_i)(\sigma) \\ 659 | \iff &\exists \sigma \in \Sigma, \forall i \in \{1,2,\dots,n\} \forall c \in \mathcal{E}(\sigma), p_i(c) \\ 660 | \iff &\exists \sigma \in \Sigma, \forall c \in \mathcal{E}(\sigma), \forall i \in \{1,2,\dots,n\}, p_i(c) \\ 661 | \implies &\exists \sigma \in \Sigma, \exists c \in \mathcal{E}(\sigma), \forall i \in \{1,2,\dots,n\}, p_i(c) \\ 662 | \iff &\exists c \in \mathcal{C}, \forall i \in \{1,2,\dots,n\}, p_i(c) \\ 663 | \iff &Consistent_{\mathcal{C}}(\{p_1,p_2,\dots,p_n\}) 664 | \end{align} 665 | \end{proof} 666 | 667 | We will use this lemma to ensure the consistency of properties of consensus values that correspond to decided properties of protocol states (via $H$). We will call these properties ``the decided properties of consensus values": 668 | 669 | \begin{defn}[Decided on properties of consensus values] 670 | \begin{align} 671 | Decided_{\mathcal{C},t}&: P_{\mathcal{C}} \times \Sigma_t \to \{True, False\} \\ 672 | Decided_{\mathcal{C},t}(p, \sigma)&= Decided_{\Sigma,t}(H(p), \sigma) 673 | \end{align} 674 | \end{defn} 675 | 676 | In addition to deciding on properties of protocol states, nodes can also make decisions on properties of consensus values. 677 | 678 | \begin{defn}[Decisions on properties of consensus values] 679 | $$Decisions_{\mathcal{C},t} : \Sigma_t \to \mathcal{P}(P_{\mathcal{C}})$$ 680 | $$Decisions_{\mathcal{C},t}(\sigma) = \{q \in P_{\mathcal{C}}: H(q) \in Decisions_{\Sigma,t}(\sigma)\}$$ 681 | \end{defn} 682 | 683 | We are finally able to give our last consensus safety theorem, which shows that decisions on properties of consensus values are consistent if there aren't too many faults: 684 | 685 | \begin{thm}[$n$-party consensus safety for properties of the consensus] 686 | $\forall \sigma_i \in \Sigma_t$, 687 | $$F(\bigcup_{i=1}^n \sigma_i) \leq t \implies Consistent_{\mathcal{C}}(\bigcup_{i=1}^n Decisions_{\mathcal{C},t}(\sigma_i))$$ 688 | \end{thm} 689 | 690 | 691 | \begin{proof} 692 | \begin{align} 693 | F(\bigcup_{i=1}^n \sigma_i) \leq t\\ 694 | \implies& Consistent_\Sigma(\bigcup_{i=1}^n Decisions_{\Sigma,t}(\sigma_i)) \\ 695 | \implies& Consistent_\Sigma(\{ p \in \bigcup_{i=1}^n Decisions_{\Sigma,t}(\sigma_i): \exists q \in P_{\mathcal{C}}, p = H(q)\})\\ 696 | \iff& Consistent_\Sigma(\bigcup_{q \in P_{\mathcal{C}} ~:~ H(q) \in \bigcup_{i=1}^n Decisions_{\Sigma,t}(\sigma_i)} \{H(q)\} )\\ 697 | %\implies& \forall H \{H(p_1), H(p_2), \dotsH(p_n)\} \in Decisions_{\Sigma,t}(\{ \sigma_1,\sigma_2, \sigma_3,\dots,\sigma_n \} )),\\ 698 | % &~~~~~~~~~~~~~~ Consistent_\Sigma(\{H(p_1), H(p_2), \dotsH(p_n)\}) \\ 699 | \iff& Consistent_{\mathcal{C}}(\{q \in P_{\mathcal{C}}: H(q) \in \bigcup_{i=1}^n Decisions_{\Sigma,t}(\sigma_i)\}) \\ 700 | \iff& Consistent_{\mathcal{C}}(\bigcup_{i=1}^n Decisions_{\mathcal{C},t}(\sigma_i)) 701 | \end{align} 702 | \end{proof} 703 | 704 | And once again, we note the contrapositive of this theorem, which shows that if there are inconsistent decisions on properties of the consensus, then it must be that more than $t$ weight of validators are Byzantine and equivocating: 705 | 706 | $$ 707 | \neg Consistent_{\mathcal{C}}(\bigcup_{i=1}^n Decisions_{\mathcal{C},t}(\sigma_i)) \implies F(\bigcup_{i=1}^n \sigma_i) > t 708 | $$ 709 | 710 | This concludes the safety proof for the minimal CBC Casper family of protocols. 711 | 712 | \pagebreak 713 | \input{examples.tex} 714 | 715 | \pagebreak 716 | \input{conclusion.tex} 717 | 718 | \bibliography{ethereum} 719 | \bibliographystyle{IEEEtran} 720 | 721 | \pagebreak 722 | \input{appendix.tex} 723 | 724 | \iffalse 725 | \input{technical-lemmas.tex} 726 | 727 | \input{safety-oracle.tex} 728 | 729 | \input{liveness.tex} 730 | \fi 731 | 732 | 733 | \end{document} 734 | -------------------------------------------------------------------------------- /conclusion.tex: -------------------------------------------------------------------------------- 1 | \section{Discussion and Conclusion} 2 | 3 | In summary, we've partially specified a family of consensus protocols and shown that every member of this family has asynchronous, Byzantine-fault-tolerant consensus safety. Furthermore, we've given examples of members of the family of increasing complexity to demonstrate the power and flexibility of our approach to correct-by-construction consensus protocol design. 4 | 5 | Although the protocols given here are not fully enough defined to serve as production systems, we contend that the specifications given here make it easy to define many practical protocols. For example, we have been able to show that it's possible to do consensus with asynchronous Byzantine-fault-tolerant safety with the same network overhead as Nakamoto consensus. We strongly suspect that CBC Casper protocols are qualitatively different from traditional consensus protocols like Paxos\cite{paxos} or PBFT\cite{Castro_Liskov_1999_pbft}. 6 | 7 | Notable related work that isn't discussed here includes work on fault attribution and classification, the detection of decisions in CBC Casper protocols, light client CBC Casper protocols, running CBC Casper with extra-protocol fault tolerance thresholds, doing validator set changes, guaranteeing the validity and availability of messages, and work on ensuring the existence of incentives in proof-of-stake. 8 | 9 | Work on liveness, validator strategies for making consensus messages, and for preventing denial-of-service attacks is ongoing. Furthermore, work of parametrizing penalties and rewards for security-deposit based proof-of-stake is in relatively early stages. 10 | 11 | Exploration of the CBC Casper family of protocols (and their implementations) is in early stages, and we have relatively very little undertanding of what would make an ``ideal" estimator, or of what kind of estimators lead to the lowest latency or lowest overhead decisions. For example, Vitalik's discussion of latest message-based estimators vs ``immediate" message-driven fork choice rules\cite{vitalik-FFG-CBC-wars-tweet-thread}. 12 | 13 | The work shared here is supposed to be the simplest formalization that will give the reader an understanding of the logic behind the proof of asynchronous Byzantine-fault-tolerant safety for the broadest family of CBC Casper consensus protocols. It isn't meant to be a complete specification of a consensus protocol, nor does the specification represent the best way to implement even this partial specification. We therefore primarily hope that readers find this work to be educational, and secondarily that it puts them in a position to contribute to ``CBC Casper research". 14 | -------------------------------------------------------------------------------- /ethereum.bib: -------------------------------------------------------------------------------- 1 | @misc{orphanBitcoin, 2 | title = {{Orphan Blocks}}, 3 | url = "https://bitcoin.org/en/developer-guide#orphan-blocks", 4 | year = "2017", 5 | month = "September", 6 | } 7 | 8 | @inproceedings{Castro_Liskov_1999_pbft, 9 | title = {{Practical Byzantine Fault Tolerance}}, 10 | author = {{Miguel Castro and Barbara Liskov}}, 11 | url = "http://pmg.lcs.mit.edu/papers/osdi99.pdf", 12 | year = "1999", 13 | month = "February", 14 | booktitle = {{Proceedings of the Third Symposium on Operating Systems Design and Implementation}}, 15 | address = "New Orleans, USA", 16 | } 17 | @MISC{vitalik-FFG-CBC-wars-tweet-thread, 18 | author = {{Vitalik Buterin}}, 19 | url = "https://twitter.com/vitalikbuterin/status/1029900695925706753?lang=en" 20 | } 21 | 22 | @MISC{vitalik2017casperffg, 23 | title = {{Casper the Friendly Finality Gadget}}, 24 | author = {{Vitalik Buterin and Virgil Griffith}}, 25 | url = "https://arxiv.org/pdf/1710.09437.pdf", 26 | year = "2017", 27 | } 28 | 29 | 30 | @article{Fischer_Lynch_Paterson_FLP_Impossibility_1985, 31 | title = {{Impossibility of Distributed Consensus with One Faulty Process}}, 32 | author = "Michael J. Fischer and Nancy A. Lynch and Michael S. Paterson", 33 | url = "https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf", 34 | journal = {{Journal of the Assccktion for Computing Machinery}}, 35 | volume = "32", 36 | number = "2", 37 | year = "1985", 38 | month = "April", 39 | pages = "374-382", 40 | } 41 | 42 | @MISC{GHOST, 43 | TITLE = {Secure High-Rate Transaction Processing in Bitcoin}, 44 | author = {Yonatan Sompolinsky and Aviv Zohar}, 45 | URL = {https://eprint.iacr.org/2013/881.pdf}, 46 | YEAR = {2013}, 47 | Month = {12}, 48 | } 49 | 50 | @MISC{nakamoto, 51 | TITLE = {Bitcoin: A Peer-to-Peer Electronic Cash Systems}, 52 | author = {Satoshi Nakamoto}, 53 | URL = {https://bitcoin.org/bitcoin.pdf}, 54 | YEAR = {2008}, 55 | Month = {11}, 56 | } 57 | 58 | @article{paxos, 59 | title={Paxos Made Moderately Complex}, 60 | author = "ROBBERT VAN RENESSE and DENIZ ALTINBUKEN", 61 | year = "2015", 62 | month = "April", 63 | doi = "http://dx.doi.org/10.1145/2673577", 64 | journal = "ACM Comput. Surv.", 65 | volume = "47", 66 | number = "3", 67 | address = "New York, NY, USA", 68 | note = "Article no. 42", 69 | url={http://www.cs.cornell.edu/courses/cs7412/2011sp/paxos.pdf}, 70 | } 71 | 72 | @article{lamport_1998, 73 | title={The part-time parliament}, 74 | volume={16}, 75 | DOI={10.1145/279227.279229}, 76 | number={2}, 77 | journal={ACM Transactions on Computer Systems}, 78 | author={Lamport, Leslie}, 79 | year={1998}, 80 | month={Jan}, 81 | pages={133–169} 82 | } 83 | 84 | @INPROCEEDINGS{castro1999practical, 85 | AUTHOR = {Miguel Castro and Barbara Liskov and et. al}, 86 | BOOKTITLE = {Proceedings of the Third Symposium on Operating Systems Design and Implementation}, 87 | EDITOR = {Paul J. Leach and Margo Seltzer}, 88 | LOCATION = {New Orleans}, 89 | MONTH = {February}, 90 | PAGES = {173--186}, 91 | TITLE = {Practical Byzantine fault tolerance}, 92 | VOLUME = {99}, 93 | YEAR = {1999}, 94 | } 95 | 96 | 97 | @ARTICLE{eyal2013, 98 | author = {Ittay Eyal and 99 | Emin G{\"{u}}n Sirer}, 100 | title = {Majority is not Enough: Bitcoin Mining is Vulnerable}, 101 | journal = {CoRR}, 102 | volume = {abs/1311.0243}, 103 | year = {2013}, 104 | url = {http://arxiv.org/abs/1311.0243}, 105 | timestamp = {Wed, 07 Jun 2017 14:41:57 +0200}, 106 | biburl = {http://dblp.uni-trier.de/rec/bib/journals/corr/EyalS13}, 107 | bibsource = {dblp computer science bibliography, http://dblp.org} 108 | } 109 | 110 | @MISC{bitcoinwikipos, 111 | TITLE = {Bitcoin Wiki: Proof of Stake, Cunicula's Implementation and Meni's implementation}, 112 | URL = {https://en.bitcoin.it/wiki/Proof_of_Stake#Cunicula.27s_Implementation_of_Mixed_Proof-of-Work_and_Proof-of-Stake}, 113 | YEAR = {2017}, 114 | } 115 | 116 | @MISC{slasher, 117 | AUTHOR = {Vitalik Buterin}, 118 | TITLE = {Slasher: A Punitive Proof-of-Stake Algorithm}, 119 | URL = {https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/}, 120 | YEAR = {2014}, 121 | } 122 | 123 | @ARTICLE{sompolinsky2013accelerating, 124 | AUTHOR = {Sompolinsky, Yonatan and Zohar, Aviv}, 125 | JOURNALTITLE = {IACR Cryptology ePrint Archive}, 126 | NUMBER = {881}, 127 | TITLE = {Accelerating Bitcoin's Transaction Processing. Fast Money Grows on Trees, Not Chains.}, 128 | VOLUME = {2013}, 129 | YEAR = {2013}, 130 | } 131 | 132 | @MISC{kwon2014tendermint, 133 | AUTHOR = {Kwon, Jae}, 134 | TITLE = {Tendermint: Consensus without mining}, 135 | URL = {https://tendermint.com/static/docs/tendermint.pdf}, 136 | YEAR = {2014}, 137 | } 138 | 139 | @ARTICLE{monderer1996potential, 140 | AUTHOR = {Monderer, Dov and Shapley, Lloyd S}, 141 | JOURNALTITLE = {Games and economic behavior}, 142 | NUMBER = {1}, 143 | PAGES = {124--143}, 144 | TITLE = {Potential games}, 145 | VOLUME = {14}, 146 | YEAR = {1996}, 147 | } 148 | 149 | @MISC{vasin2014blackcoin, 150 | AUTHOR = {Vasin, Pavel}, 151 | TITLE = {Blackcoin's proof-of-stake protocol v2}, 152 | URL = {http://blackcoin.co/blackcoin-pos-protocol-v2-whitepaper.pdf}, 153 | YEAR = {2014}, 154 | } 155 | 156 | @ARTICLE{king2012ppcoin, 157 | AUTHOR = {King, Sunny and Nadal, Scott}, 158 | JOURNALTITLE = {self-published paper, August}, 159 | TITLE = {Ppcoin: Peer-to-peer crypto-currency with proof-of-stake}, 160 | URL = {https://decred.org/research/king2012.pdf}, 161 | VOLUME = {19}, 162 | YEAR = {2012}, 163 | } 164 | 165 | @INPROCEEDINGS{bentov2016pos, 166 | AUTHOR = {Iddo Bentov and Ariel Gabizon and Alex Mizrahi}, 167 | BOOKTITLE = {International Conference on Financial Cryptography and Data Security}, 168 | EDITOR = {Radu Sion}, 169 | ORGANIZATION = {Springer}, 170 | PAGES = {142--157}, 171 | TITLE = {Cryptocurrencies without proof of work}, 172 | YEAR = {2016}, 173 | } 174 | 175 | @INPROCEEDINGS{selfishminingBTC, 176 | AUTHOR = {Ayelet Sapirshtein and Yonatan Sompolinsky and Aviv Zohar}, 177 | BOOKTITLE = {International Conference on Financial Cryptography and Data Security}, 178 | EDITOR = {Radu Sion}, 179 | ORGANIZATION = {Springer}, 180 | PAGES = {515--532}, 181 | TITLE = {Optimal selfish mining strategies in bitcoin}, 182 | YEAR = {2016}, 183 | } 184 | 185 | @MISC{minslashing, 186 | AUTHOR = {Vitalik Buterin}, 187 | DAY = {02}, 188 | MONTH = {03}, 189 | TITLE = {Minimal Slashing Conditions}, 190 | URL = {https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c}, 191 | YEAR = {2017}, 192 | } 193 | 194 | @MISC{truebit, 195 | AUTHOR = {Jason Teustch and Christian Reitwießner}, 196 | DAY = {07}, 197 | MONTH = {03}, 198 | TITLE = {A scalable verification solution for blockchains}, 199 | URL = {https://truebit.io/}, 200 | YEAR = {2017}, 201 | } 202 | 203 | @ARTICLE{ostrom2002, 204 | AUTHOR = {Ostrom, Elinor}, 205 | JOURNALTITLE = {unpublished paper}, 206 | PAGES = {15}, 207 | TITLE = {Type of good and collective action}, 208 | YEAR = {2002}, 209 | } 210 | 211 | @MISC{barder14, 212 | AUTHOR = {Alice Lépissier and Owen Barder}, 213 | DAY = {08}, 214 | MONTH = {09}, 215 | TITLE = {A Global Carbon Tax or Cap-and-Trade? Part 1: The Economic Arguments}, 216 | URL = {https://www.cgdev.org/blog/global-carbon-tax-or-cap-and-trade-part-1-economic-arguments}, 217 | YEAR = {2014}, 218 | } 219 | 220 | @MISC{braveICO, 221 | AUTHOR = {Jon Southurst}, 222 | DAY = {31}, 223 | MONTH = {05}, 224 | TITLE = {BAT Token Sale Causes Hours of Ethereum Network Delays}, 225 | URL = {http://www.bitsonline.com/bat-sale-ethereum-network-delays/}, 226 | YEAR = {2017}, 227 | } 228 | 229 | @REPORT{ibm2011, 230 | AUTHOR = {Richard F. Freitas and Joe Slember and Wayne Sawdon and Lawrence Chiu}, 231 | DAY = {22}, 232 | INSTITUTION = {IBM}, 233 | MONTH = {07}, 234 | TITLE = {GPFS Scans 10 Billion Files in 43 Minutes}, 235 | TYPE = {techreport}, 236 | URL = {https://domino.research.ibm.com/library/CyberDig.nsf/papers/4A50C2D66A1F90F7852578E3005A2034/$File/rj10484.pdf}, 237 | YEAR = {2011}, 238 | } 239 | 240 | @MISC{infura, 241 | AUTHOR = {Consensys}, 242 | DAY = {01}, 243 | MONTH = {06}, 244 | TITLE = {INFURA}, 245 | URL = {https://infura.io}, 246 | YEAR = {2017}, 247 | } 248 | 249 | @MISC{spectrumetcalfe, 250 | AUTHOR = {Bob Briscoe, Andrew Odlyzko, and Benjamin Tilly}, 251 | DAY = {01}, 252 | MONTH = {06}, 253 | TITLE = {Metcalfe's Law is Wrong}, 254 | URL = {http://spectrum.ieee.org/computing/networks/metcalfes-law-is-wrong}, 255 | YEAR = {2006}, 256 | } 257 | 258 | @MISC{env-econ, 259 | AUTHOR = {Tim Haab}, 260 | DAY = {23}, 261 | MONTH = {06}, 262 | TITLE = {The long run elasticity of demand for gas}, 263 | URL = {http://www.env-econ.net/2008/06/the-long-run-el.html}, 264 | YEAR = {2008}, 265 | } 266 | 267 | @INPROCEEDINGS{cornell-position, 268 | AUTHOR = {Kyle Croman and Christian Decker and Ittay Eyal and Adem Efe Gencer and Ari Juels}, 269 | BOOKTITLE = {3rd Workshop on Bitcoin and Blockchain Research}, 270 | EDITOR = {Sarah Meiklejohn and Jeremy Clark}, 271 | ORGANIZATION = {International Financial Cryptography Association}, 272 | TITLE = {On Scaling Decentralized Blockchains}, 273 | URL = {http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf}, 274 | YEAR = {2017}, 275 | } 276 | 277 | @MISC{medium-codetract, 278 | AUTHOR = {CodeTract}, 279 | DAY = {01}, 280 | MONTH = {06}, 281 | TITLE = {BAT ICO, USD 35 million in 24 seconds, gas and gasPrice}, 282 | URL = {https://medium.com/@codetractio/bat-ico-usd-35-million-in-24-seconds-gas-and-gasprice-6cdde370a615}, 283 | YEAR = {2017}, 284 | } 285 | 286 | @MISC{vitalik-uncle-rate, 287 | AUTHOR = {Vitalik Buterin}, 288 | DAY = {31}, 289 | MONTH = {10}, 290 | TITLE = {Uncle Rate and Transaction Fee Analysis}, 291 | URL = {https://blog.ethereum.org/2016/10/31/uncle-rate-transaction-fee-analysis/}, 292 | YEAR = {2016}, 293 | } 294 | 295 | @MISC{vitalik-twitter1, 296 | AUTHOR = {Vitalik Buterin}, 297 | DAY = {03}, 298 | MONTH = {06}, 299 | TITLE = {Tweet}, 300 | URL = {https://twitter.com/VitalikButerin/status/871218258212290560}, 301 | YEAR = {2017}, 302 | } 303 | 304 | @MISC{reddit-rec-miners, 305 | AUTHOR = {Hudson Jameson}, 306 | DAY = {31}, 307 | MONTH = {05}, 308 | TITLE = {Recommendations to miners to change gas limit and gas price settings}, 309 | URL = {https://www.reddit.com/r/ethereum/comments/6ehp60/recommendations_to_miners_to_change_gas_limit_and/}, 310 | YEAR = {2017}, 311 | } 312 | 313 | @MISC{coindesk-btc-txn-fee, 314 | AUTHOR = {Danny Bradbury}, 315 | DAY = {28}, 316 | MONTH = {02}, 317 | TITLE = {Bitcoin Transaction Fees To Be Slashed Tenfold}, 318 | URL = {http://www.coindesk.com/bitcoin-transaction-fees-slashed-tenfold/}, 319 | YEAR = {2014}, 320 | } 321 | 322 | @MISC{vitalik-coord, 323 | AUTHOR = {Vitalik Buterin}, 324 | DAY = {08}, 325 | MONTH = {05}, 326 | TITLE = {Engineering Security Through Coordination Problems}, 327 | URL = {http://vitalik.ca/general/2017/05/08/coordination_problems.html}, 328 | YEAR = {2017}, 329 | } 330 | 331 | @MISC{etherchaingas, 332 | AUTHOR = {Etherchain}, 333 | DAY = {01}, 334 | MONTH = {May}, 335 | TITLE = {Economic gas price estimation}, 336 | URL = {https://etherchain.org/statistics/gasPrice}, 337 | YEAR = {2017}, 338 | } 339 | 340 | @MISC{40years, 341 | AUTHOR = {Karl Rupp}, 342 | DAY = {25}, 343 | MONTH = {06}, 344 | TITLE = {40 Years of Microprocessor Trend Data}, 345 | URL = {https://www.karlrupp.net/2015/06/40-years-of-microprocessor-trend-data/}, 346 | YEAR = {2015}, 347 | } 348 | 349 | @MISC{wiki:runaway, 350 | AUTHOR = {Wikipedia}, 351 | NOTE = {[Online; accessed 5-May-2017]}, 352 | TITLE = {Runaway climate change --- Wikipedia{,} The Free Encyclopedia}, 353 | URL = {https://en.wikipedia.org/w/index.php?title=Runaway_climate_change&oldid=776345569}, 354 | YEAR = {2017}, 355 | } 356 | 357 | @MISC{wood2014ethereum, 358 | AUTHOR = {Gavin Wood}, 359 | TITLE = {Ethereum: A Secure Decentralized Generalized Transaction Ledger}, 360 | URL = {http://yellowpaper.io/}, 361 | YEAR = {2014}, 362 | } 363 | 364 | @ARTICLE{weitzman1974prices, 365 | AUTHOR = {Martin L Weitzman}, 366 | JOURNALTITLE = {The review of economic studies}, 367 | NUMBER = {4}, 368 | PAGES = {477--491}, 369 | TITLE = {Prices vs. quantities}, 370 | VOLUME = {41}, 371 | YEAR = {1974}, 372 | } 373 | 374 | @MISC{bip:141, 375 | AUTHOR = {Eric Lombrozo, Johnson Lau, and Pieter Wuille}, 376 | DAY = {21}, 377 | MONTH = {12}, 378 | TITLE = {BIP 141: Segregated Witness}, 379 | URL = {https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki}, 380 | YEAR = {2015}, 381 | } 382 | 383 | @BOOK{knight1921risk, 384 | AUTHOR = {Knight, Frank H}, 385 | PUBLISHER = {Courier Corporation}, 386 | TITLE = {Risk, uncertainty and profit}, 387 | YEAR = {1921}, 388 | } 389 | 390 | @INPROCEEDINGS{fc17ai, 391 | AUTHOR = {McCorry, Patrick and Shahandashti, Siamak F. and Hao, Feng}, 392 | BOOKTITLE = {Proceedings of Financial Cryptography and Data Security}, 393 | EDITOR = {Rainer Böhme and Tatsuaki Okamoto}, 394 | ORGANIZATION = {International Financial Cryptography Association}, 395 | TITLE = {A Smart Contract for Boardroom Voting with Maximum Voter Privacy}, 396 | URL = {http://fc17.ifca.ai/preproceedings/paper_80.pdf}, 397 | YEAR = {2017}, 398 | } 399 | 400 | @ARTICLE{vigna13fibonacci, 401 | AUTHOR = {Sebastiano Vigna}, 402 | JOURNALTITLE = {CoRR}, 403 | TITLE = {Fibonacci Binning}, 404 | URL = {http://arxiv.org/abs/1312.3749}, 405 | VOLUME = {abs/1312.3749}, 406 | YEAR = {2013}, 407 | } 408 | 409 | @MISC{wiki:ricochet, 410 | AUTHOR = {Wikipedia}, 411 | NOTE = {[Online; accessed 28-February-2017]}, 412 | TITLE = {Ricochet (software) --- Wikipedia{,} The Free Encyclopedia}, 413 | URL = {https://en.wikipedia.org/w/index.php?title=Ricochet_(software)&oldid=755044411}, 414 | YEAR = {2016}, 415 | } 416 | 417 | @ARTICLE{darknet, 418 | AUTHOR = {Manlio De Domenico and Alex Arenas}, 419 | DOI = {10.1103/PhysRevE.95.022313}, 420 | ISSUE = {2}, 421 | JOURNALTITLE = {Phys. Rev. E}, 422 | MONTH = {Feb}, 423 | PAGES = {022313}, 424 | TITLE = {Modeling structure and resilience of the dark network}, 425 | URL = {http://link.aps.org/doi/10.1103/PhysRevE.95.022313}, 426 | VOLUME = {95}, 427 | YEAR = {2017}, 428 | } 429 | 430 | @ARTICLE{borgatti1998network, 431 | AUTHOR = {Borgatti, Stephen P and Jones, Candace and Everett, Martin G}, 432 | JOURNALTITLE = {Connections}, 433 | NUMBER = {2}, 434 | PAGES = {27--36}, 435 | TITLE = {Network measures of social capital}, 436 | VOLUME = {21}, 437 | YEAR = {1998}, 438 | } 439 | 440 | @MISC{wiki:torchat, 441 | AUTHOR = {Wikipedia}, 442 | NOTE = {[Online; accessed 28-February-2017]}, 443 | TITLE = {TorChat --- Wikipedia{,} The Free Encyclopedia}, 444 | URL = {https://en.wikipedia.org/w/index.php?title=TorChat&oldid=728783759}, 445 | YEAR = {2016}, 446 | } 447 | 448 | @MISC{wiki:tormessenger, 449 | AUTHOR = {Wikipedia}, 450 | NOTE = {[Online; accessed 28-February-2017]}, 451 | TITLE = {Tor (anonymity network) --- Wikipedia{,} The Free Encyclopedia}, 452 | URL = {https://en.wikipedia.org/w/index.php?title=Tor_(anonymity_network)#Tor_Messenger&oldid=767770868}, 453 | YEAR = {2017}, 454 | } 455 | 456 | @REPORT{pagerank, 457 | ABSTRACT = {The importance of a Web page is an inherently subjective matter, which depends on the readers interests, knowledge and attitudes. But there is still much that can be said objectively about the relative importance of Web pages. This paper describes PageRank, a mathod for rating Web pages objectively and mechanically, effectively measuring the human interest and attention devoted to them. We compare PageRank to an idealized random Web surfer. We show how to efficiently compute PageRank for large numbers of pages. And, we show how to apply PageRank to search and to user navigation.}, 458 | AUTHOR = {Lawrence Page and Sergey Brin and Rajeev Motwani and Terry Winograd}, 459 | INSTITUTION = {Stanford InfoLab}, 460 | MONTH = {November}, 461 | NOTE = {Previous number = SIDL-WP-1999-0120}, 462 | NUMBER = {1999-66}, 463 | TITLE = {The PageRank Citation Ranking: Bringing Order to the Web.}, 464 | TYPE = {Technical Report}, 465 | URL = {http://ilpubs.stanford.edu:8090/422/}, 466 | YEAR = {1999}, 467 | } 468 | 469 | @BOOK{everton2012disrupting, 470 | AUTHOR = {Everton, Sean F}, 471 | PUBLISHER = {Cambridge University Press}, 472 | TITLE = {Disrupting dark networks}, 473 | VOLUME = {34}, 474 | YEAR = {2012}, 475 | } 476 | 477 | @ARTICLE{broder2000graph, 478 | AUTHOR = {Andrei Broder and Ravi Kumar and Farzin Maghoul and Prabhakar Raghavan and Sridhar Rajagopalan and Raymie Stata and Andrew Tomkins and Janet Wiener}, 479 | JOURNALTITLE = {Computer networks}, 480 | NUMBER = {1}, 481 | PAGES = {309--320}, 482 | TITLE = {Graph structure in the web}, 483 | VOLUME = {33}, 484 | YEAR = {2000}, 485 | } 486 | 487 | @ARTICLE{rfc7686, 488 | AUTHOR = {Appelbaum, Jacob and Muffet, Alex}, 489 | ISSN = {2070-1721}, 490 | JOURNALTITLE = {Internet Engineering Task Force RFC}, 491 | MONTH = {Oct}, 492 | TITLE = {The ``.onion'' Special-Use Domain Name}, 493 | URL = {https://tools.ietf.org/html/rfc7686}, 494 | VOLUME = {7686}, 495 | YEAR = {2015}, 496 | } 497 | 498 | @ARTICLE{clauset2009power, 499 | AUTHOR = {Clauset, Aaron and Shalizi, Cosma Rohilla and Newman, Mark EJ}, 500 | JOURNALTITLE = {SIAM review}, 501 | NUMBER = {4}, 502 | PAGES = {661--703}, 503 | TITLE = {Power-law distributions in empirical data}, 504 | VOLUME = {51}, 505 | YEAR = {2009}, 506 | } 507 | 508 | @ARTICLE{meusel2015graph, 509 | AUTHOR = {Meusel, Robert and Vigna, Sebastiano and Lehmberg, Oliver and Bizer, Christian}, 510 | JOURNALTITLE = {The Journal of Web Science}, 511 | NUMBER = {1}, 512 | TITLE = {The Graph Structure in the Web--Analyzed on Different Aggregation Levels}, 513 | VOLUME = {1}, 514 | YEAR = {2015}, 515 | } 516 | 517 | @ARTICLE{Serrano2007, 518 | AUTHOR = {Serrano, M. Ángeles and Maguitman, Ana and Boguñá, Marián and Fortunato, Santo and Vespignani, Alessandro}, 519 | DOI = {10.1145/1255438.1255442}, 520 | ISSN = {1559-1131}, 521 | JOURNALTITLE = {ACM Trans. Web}, 522 | KEYWORDS = {Web graph structure, Web measurement, crawler biases, statistical analysis}, 523 | MONTH = {08}, 524 | NUMBER = {2}, 525 | TITLE = {Decoding the Structure of the WWW: A Comparative Analysis of Web Crawls}, 526 | URL = {http://doi.acm.org/10.1145/1255438.1255442}, 527 | VOLUME = {1}, 528 | YEAR = {2007}, 529 | } 530 | 531 | @ARTICLE{bollobas2004robustness, 532 | AUTHOR = {Bollobás, Béla and Riordan, Oliver}, 533 | JOURNALTITLE = {Internet Mathematics}, 534 | NUMBER = {1}, 535 | PAGES = {1--35}, 536 | TITLE = {Robustness and vulnerability of scale-free random graphs}, 537 | VOLUME = {1}, 538 | YEAR = {2004}, 539 | } 540 | 541 | @ARTICLE{barabasi1999emergence, 542 | AUTHOR = {Barabási, Albert-László and Albert, Réka}, 543 | JOURNALTITLE = {science}, 544 | NUMBER = {5439}, 545 | PAGES = {509--512}, 546 | TITLE = {Emergence of scaling in random networks}, 547 | VOLUME = {286}, 548 | YEAR = {1999}, 549 | } 550 | 551 | @ARTICLE{willinger2013internet, 552 | AUTHOR = {Willinger, Walter and Roughan, Matthew}, 553 | JOURNALTITLE = {ACM SIGCOMM eBook: Recent Advances in Networking}, 554 | TITLE = {Internet topology research redux}, 555 | YEAR = {2013}, 556 | } 557 | 558 | @ARTICLE{willinger2009mathematics, 559 | AUTHOR = {Willinger, Walter and Alderson, David and Doyle, John C}, 560 | JOURNALTITLE = {Notices of the AMS}, 561 | NUMBER = {5}, 562 | PAGES = {586--599}, 563 | TITLE = {Mathematics and the internet: A source of enormous confusion and great potential}, 564 | VOLUME = {56}, 565 | YEAR = {2009}, 566 | } 567 | 568 | @ARTICLE{pansiot1998routes, 569 | AUTHOR = {Jean-Jacques Pansiot and Dominique Grad}, 570 | JOURNALTITLE = {ACM SIGCOMM Computer Communication Review}, 571 | NUMBER = {1}, 572 | PAGES = {41--50}, 573 | TITLE = {On routes and multicast trees in the Internet}, 574 | VOLUME = {28}, 575 | YEAR = {1998}, 576 | } 577 | 578 | @THESIS{jovanovic2001modeling, 579 | AUTHOR = {Jovanovic, Mihajlo A}, 580 | INSTITUTION = {University of Cincinnati}, 581 | TITLE = {Modeling large-scale peer-to-peer networks and a case study of Gnutella}, 582 | TYPE = {mathesis}, 583 | YEAR = {2001}, 584 | } 585 | 586 | @ARTICLE{barabasi2000scale, 587 | AUTHOR = {Barabási, Albert-László and Albert, Réka and Jeong, Hawoong}, 588 | JOURNALTITLE = {Physica A: Statistical Mechanics and its Applications}, 589 | NUMBER = {1}, 590 | PAGES = {69--77}, 591 | TITLE = {Scale-free characteristics of random networks: the topology of the world-wide web}, 592 | VOLUME = {281}, 593 | YEAR = {2000}, 594 | } 595 | 596 | @ARTICLE{siganos2003power, 597 | AUTHOR = {Siganos, Georgos and Faloutsos, Michalis and Faloutsos, Petros and Faloutsos, Christos}, 598 | JOURNALTITLE = {IEEE/ACM Transactions on Networking (TON)}, 599 | NUMBER = {4}, 600 | PAGES = {514--524}, 601 | TITLE = {Power laws and the AS-level internet topology}, 602 | VOLUME = {11}, 603 | YEAR = {2003}, 604 | } 605 | 606 | @ARTICLE{albert2001physics, 607 | AUTHOR = {Albert-László Barabási, July}, 608 | JOURNALTITLE = {Physics Web http://www.physicsweb.org/article/world/14/7/09}, 609 | TITLE = {The physics of the Web}, 610 | YEAR = {2001}, 611 | } 612 | 613 | @ARTICLE{cohen2001breakdown, 614 | AUTHOR = {Cohen, Reuven and Erez, Keren and Ben-Avraham, Daniel and Havlin, Shlomo}, 615 | JOURNALTITLE = {Physical review letters}, 616 | NUMBER = {16}, 617 | PAGES = {3682}, 618 | TITLE = {Breakdown of the Internet under intentional attack}, 619 | VOLUME = {86}, 620 | YEAR = {2001}, 621 | } 622 | 623 | @ARTICLE{albert2000error, 624 | AUTHOR = {Albert, Réka and Jeong, Hawoong and Barabási, Albert-László}, 625 | JOURNALTITLE = {Nature}, 626 | NUMBER = {6794}, 627 | PAGES = {378--382}, 628 | TITLE = {Error and attack tolerance of complex networks}, 629 | VOLUME = {406}, 630 | YEAR = {2000}, 631 | } 632 | 633 | @ARTICLE{adamic2000power, 634 | AUTHOR = {Adamic, Lada A and Huberman, Bernardo A}, 635 | JOURNALTITLE = {Science}, 636 | NUMBER = {5461}, 637 | PAGES = {2115--2115}, 638 | TITLE = {Power-law distribution of the world wide web}, 639 | VOLUME = {287}, 640 | YEAR = {2000}, 641 | } 642 | 643 | @MISC{tormetrics, 644 | AUTHOR = {The Tor Project}, 645 | MONTH = {January}, 646 | TITLE = {TorMetrics --- Unique .onion addresses}, 647 | URL = {https://metrics.torproject.org/hidserv-dir-onions-seen.html}, 648 | YEAR = {2017}, 649 | } 650 | -------------------------------------------------------------------------------- /examples.tex: -------------------------------------------------------------------------------- 1 | \section{Example Protocols} 2 | \subsection{Preliminary Definitions} 3 | 4 | We need to develop a bit of language before giving example protocols. Specifically, we are going to define the terms required for us to talk about the estimates of the latest messages from non-equivocating validators. 5 | 6 | The observed validators in a set of messages are all validators who have sent at least one of those messages: 7 | 8 | \begin{defn}[Observed validators] 9 | \begin{align*} 10 | Observed:& \mathcal{P}(M) \to \mathcal{P}(\mathcal{V}) \\ 11 | Observed(\sigma) =& \{ Sender(m) : m \in \sigma \} \\ 12 | \end{align*} 13 | \end{defn} 14 | \begin{defn} 15 | \begin{align*} 16 | Later:&M \times \mathcal{P}(M) \to \mathcal{P}(M) \\ 17 | Later(m, \sigma) =& \{m' \in \sigma : m \in Justification(m') \} 18 | \end{align*} 19 | \end{defn} 20 | 21 | The messages from a validator in a set of messages are all messages such that the sender of the message is that validator: 22 | 23 | \begin{defn}[Message From a Sender] 24 | \begin{align*} 25 | From\_Sender:& \mathcal{V} \times \mathcal{P}(M) \to \mathcal{P}(M) \\ 26 | From\_Sender(v, \sigma) =& \{m \in \sigma : Sender(m) = v \} 27 | \end{align*} 28 | \end{defn} 29 | 30 | Similarly, we can define the messages from a group: 31 | 32 | \begin{defn}[Messages From a Group] 33 | \begin{align*} 34 | From\_Group:& \mathcal{P}(\mathcal{V}) \times \mathcal{P}(M) \to \mathcal{P}(M) \\ 35 | From\_Group(V, \sigma) =& \{m \in \sigma : Sender(m) \in V \} \\ 36 | \end{align*} 37 | \end{defn} 38 | 39 | 40 | 41 | \begin{defn} 42 | \begin{align*} 43 | Later\_From:& M \times \mathcal{V} \times \mathcal{P}(M) \\ 44 | Later\_From(m, v, \sigma) =& Later(m, \sigma) \cap From\_Sender(v, \sigma) 45 | \end{align*} 46 | \end{defn} 47 | 48 | \iffalse 49 | \begin{lemma}[Monotonicity of Later\_From] 50 | $$ 51 | m' \in Later\_From(m,v,\sigma) \implies Later\_From(m', v, \sigma) \subseteq Later\_From(m, v, \sigma) 52 | $$ 53 | \end{lemma} 54 | 55 | \begin{proof} 56 | \begin{align*} 57 | m' \in Later\_From(m, v, \sigma) &\implies m' \in Later(m, \sigma) \cap From\_Sender(v, \sigma)\\ 58 | &\implies m' \in Later(m, \sigma) \\ 59 | &\implies m \in Justification(m') \\ 60 | &\implies m \in Justification(m') \land \forall m'' \in Later\_From(m',v,\sigma), \\ 61 | &~~~~~m'' \in Later(m', \sigma) 62 | \\ 63 | &\implies m \in Justification(m') \land \forall m'' \in Later\_From(m',v,\sigma), \\ 64 | &~~~~~m' \in Justification(m'') 65 | \\ 66 | &\implies m \in Justification(m') \land \forall m'' \in Later\_From(m',v,\sigma), \\ 67 | &~~~~~Justification(m') \subseteq Justification(m'') 68 | \\ 69 | &\implies \forall m'' \in Later\_From(m',v,\sigma), m \in Justification(m') \\ 70 | &~~~~~\land Justification(m') \subseteq Justification(m'') 71 | \\ 72 | &\implies \forall m'' \in Later\_From(m',v,\sigma), m \in Justification(m'') \\ 73 | &\implies \forall m'' \in Later\_From(m',v,\sigma), m'' \in Later(m, \sigma) \\ 74 | &\implies \forall m'' \in Later\_From(m',v,\sigma), m'' \in Later(m, \sigma) \land m'' \in From\_Sender(v, \sigma) \\ 75 | &\implies \forall m'' \in Later\_From(m',v,\sigma), m'' \in Later(m, \sigma) \cap From\_Sender(v, \sigma) \\ 76 | &\implies \forall m'' \in Later\_From(m',v,\sigma), m'' \in Later\_From(m, v, \sigma) \\ 77 | &\implies Later\_From(m',v,\sigma) \subseteq Later\_From(m,v,\sigma) 78 | \end{align*} 79 | \end{proof} 80 | \fi 81 | 82 | \begin{defn}[Latest Message] 83 | \begin{align*} 84 | L_M:& \mathcal{P}(M) \to (\mathcal{V} \to \mathcal{P}(M)) \\ 85 | L_M(\sigma)(v) =& \{m \in From\_Sender(v, \sigma): Later\_From(m, v, \sigma) = \emptyset \} 86 | \end{align*} 87 | \end{defn} 88 | 89 | \begin{defn}[Latest message driven estimator] 90 | \begin{align*} 91 | Latest\_Message\_Driven:& \mathcal{P}(C)^\Sigma \to \{True, False\} \\ 92 | Latest\_Message\_Driven(\mathcal{E}) :\Leftrightarrow& \exists \hat{\mathcal{E}} \in \mathcal{P}(C)^{\mathcal{P}(M)^\mathcal{V}}, ~~\mathcal{E} = \hat{\mathcal{E}} \circ L_M 93 | \end{align*} 94 | \end{defn} 95 | 96 | \begin{defn}[Latest Estimates] 97 | \begin{align*} 98 | L_E:&\Sigma \to (\mathcal{V} \to \mathcal{P}(\mathcal{C})) \\ 99 | L_E(\sigma)(v) =& \{Estimate(m): m \in L_M(\sigma)(v)\} \\ 100 | \end{align*} 101 | \end{defn} 102 | 103 | \begin{defn}[Latest estimate driven estimator] 104 | \begin{align*} 105 | Latest\_Estimate\_Driven:& \mathcal{P}(C)^\Sigma \to \{True, False\} \\ 106 | Latest\_Estimate\_Driven(\mathcal{E}) :\Leftrightarrow& \exists \hat{\mathcal{E}} \in \mathcal{P}(C)^{\mathcal{P}(C)^\mathcal{V}}, ~~\mathcal{E} = \hat{\mathcal{E}} \circ L_E 107 | \end{align*} 108 | \end{defn} 109 | 110 | \begin{lemma}[Non-equivocating validators have at most one latest message] 111 | $\forall v \in \mathcal{V}$, 112 | $$ 113 | v \notin E(\sigma) \implies |L_M(\sigma)(v)| \leq 1 114 | $$ 115 | \end{lemma} 116 | 117 | 118 | \begin{proof} 119 | We will prove the contrapositive , $|L_M(\sigma)(v)| > 1 \implies v \in E(\sigma)$ 120 | \begin{align*} 121 | |L_M(\sigma)(v)| > 1 &\implies |\{m \in From\_Sender(v, \sigma) : Later\_From(m, v, \sigma) = \emptyset \}| > 1 122 | \\ 123 | &\implies \exists m_1 \in From\_Sender(v, \sigma), \exists m_2 \in From\_Sender(v, \sigma), m_1 \neq m_2\\ 124 | &~~~\land Later\_From(m_1, v, \sigma) = \emptyset \land Later\_From(m_2, v, \sigma) = \emptyset 125 | \\ 126 | &\iff \exists m_1 \in From\_Sender(v, \sigma), \exists m_2 \in From\_Sender(v, \sigma), m_1 \neq m_2\\ 127 | &~~~\land Later(m_1, \sigma) \cap From\_Sender(v, \sigma) = \emptyset \land Later(m_2, \sigma) \cap From\_Sender(v, \sigma) = \emptyset 128 | \\ 129 | &\implies \exists m_1 \in From\_Sender(v, \sigma), \exists m_2 \in From\_Sender(v, \sigma), m_1 \neq m_2\\ 130 | &~~~\land \nexists m^* \in From\_Sender(v, \sigma), m^* \in Later(m_1, \sigma) \\ 131 | &~~~\land \nexists m^{**} \in From\_Sender(v, \sigma), m^{**} \in Later(m_2, \sigma) 132 | \\ 133 | &\implies \exists m_1 \in From\_Sender(v, \sigma), \exists m_2 \in From\_Sender(v, \sigma), m_1 \neq m_2\\ 134 | &~~~\land \nexists m^* \in From\_Sender(v, \sigma), m_1 \in Justification(m^*) \\ 135 | &~~~\land \nexists m^{**} \in From\_Sender(v, \sigma), m_2 \in Justification(m^{**}) 136 | \\ 137 | &\implies \exists m_1 \in From\_Sender(v, \sigma), \exists m_2 \in From\_Sender(v, \sigma), m_1 \neq m_2\\ 138 | &~~~\land \forall m^* \in From\_Sender(v, \sigma), m_1 \notin Justification(m^*) \\ 139 | &~~~\land \forall m^{**} \in From\_Sender(v, \sigma), m_2 \notin Justification(m^{**}) 140 | \\ 141 | &\implies \exists m_1 \in \sigma : Sender(m_1) = v, \exists m_2 \in \sigma : Sender(m_2) = v, m_1 \neq m_2\\ 142 | &~~~\land m_1 \notin Justification(m_2, \sigma) \land m_2 \notin Justification(m_1, \sigma) 143 | \\ 144 | &\implies \exists m_1 \in \sigma : Sender(m_1) = v, \exists m_2 \in \sigma : Sender(m_2) = v, \\ 145 | &~~~~~~~Sender(m_1) = Sender(m_2) \land m_1 \neq m_2\\ 146 | &~~~\land m_1 \notin Justification(m_2, \sigma) \land m_2 \notin Justification(m_1, \sigma) 147 | \\ 148 | &\implies \exists m_1 \in \sigma, \exists m_2 \in \sigma, Sender(m_1) = Sender(m_2) \land m_1 \neq m_2\\ 149 | &~~~\land m_1 \notin Justification(m_2, \sigma) \land m_2 \notin Justification(m_1, \sigma) 150 | \\ 151 | &\iff v \in E(\sigma) 152 | \end{align*} 153 | \end{proof} 154 | 155 | 156 | \begin{defn}[$\preceq$] 157 | \begin{align*} 158 | \cdot \preceq \cdot &: M \times M \to \{True, False\} \\ 159 | m_1 \preceq m_2 &:\Leftrightarrow |Justification(m_1)| \geq |Justification(m_2)| 160 | \end{align*} 161 | \end{defn} 162 | 163 | 164 | \begin{lemma} 165 | $\forall \sigma \in \Sigma, \forall S \subseteq \sigma$ 166 | 167 | $(S, \preceq)$ is a total order. 168 | \end{lemma} 169 | 170 | \begin{proof} 171 | Starting from the fact that all protocol states are finite, we show that every justification of every message in $\sigma$ (and in therefore in $S$) is finite. 172 | \begin{align*} 173 | &\forall \sigma \in \Sigma, \exists n \in \mathbb{N}, n = |\sigma| \\ 174 | &\implies \forall \sigma \in \Sigma, \exists n \in \mathbb{N}, n = |\sigma| \\ 175 | &~~~~\land \forall m \in \sigma, Justification(m) \subseteq \sigma 176 | \\ 177 | &\implies \forall \sigma \in \Sigma, \exists n \in \mathbb{N}, n = |\sigma| \\ 178 | &~~~~\land \forall m \in \sigma, |Justification(m)| \leq |\sigma| 179 | \\ 180 | &\implies \forall \sigma \in \Sigma, \exists n \in \mathbb{N}, n = |\sigma| \\ 181 | &~~~~\land \forall m \in \sigma, |Justification(m)| \leq n 182 | \\ 183 | &\implies \forall \sigma \in \Sigma, \exists n \in \mathbb{N}, n = |\sigma| \\ 184 | &~~~~\land \forall m \in \sigma, \exists n' \in \mathbb{N}, n' = |Justification(m)| 185 | \\ 186 | &\implies \forall \sigma \in \Sigma, \\ 187 | &~~~~~\forall m \in \sigma, \exists n' \in \mathbb{N}, n' = |Justification(m)| 188 | \\ 189 | &\implies \forall \sigma \in \Sigma, \forall S \subseteq \sigma, \\ 190 | &~~~~~\forall m \in \sigma, \exists n' \in \mathbb{N}, n' = |Justification(m)| 191 | \\ 192 | &\implies \forall \sigma \in \Sigma, \forall S \subseteq \sigma, \\ 193 | &~~~~~\forall m \in S, \exists n' \in \mathbb{N}, n' = |Justification(m)| 194 | \end{align*} 195 | 196 | This means that 197 | 198 | $$ 199 | \exists f \in \mathbb{N}^S, \forall m \in S, f(m) = |Justification(m)| 200 | $$ 201 | 202 | And we have the following equivalence for such a function $f$: 203 | 204 | $$ 205 | m_1 \preceq m_2 \iff |Justification(m_1)| \geq |Justification(m_2))| \iff f(m_1) \geq f(m_2) 206 | $$ 207 | 208 | Therefore, if $(Im(f), \geq)$ is a total order, then so is $(S, \preceq)$. Note that $Im(f)$ denoted the image of $f$, $\{n \in \mathbb{N}: \exists m \in S, f(m) = n\}$. Furthermore, we know that $(\mathbb{N}, \geq)$ is a total order, and it follows that $(Im(f), \geq)$ is a total order, which in turn means that $(S, \preceq)$ is a total order. 209 | \end{proof} 210 | 211 | \begin{lemma}[Monotonicity of Justifications] 212 | $$ 213 | m' \in Later(m, \sigma) \Longrightarrow Justification(m) \subseteq Justification(m') 214 | $$ 215 | \end{lemma} 216 | 217 | \begin{proof} 218 | \begin{align*} 219 | &m' \in Later(m, \sigma) \\ 220 | \Longleftrightarrow& m' \in \{m^* \in \sigma : m \in Justification(m^*) \} \\ 221 | \Longrightarrow& m \in Justification(m') \\ 222 | \Longrightarrow& \exists \sigma' \in \Sigma, m \in \sigma', \sigma' = Justification(m') \\ 223 | \Longrightarrow& \exists \sigma' \in \Sigma, m \in \sigma', \sigma' = Justification(m') \land Justification(m) \subseteq \sigma' \\ 224 | \Longrightarrow& \exists \sigma' \in \Sigma, m \in \sigma', Justification(m) \subseteq Justification(m') \\ 225 | \Longrightarrow& Justification(m) \subseteq Justification(m') \\ 226 | \end{align*} 227 | \end{proof} 228 | 229 | \begin{lemma} 230 | The minimal elements in $(From\_Sender(v, \sigma), \preceq)$ are the latest messages of validator $v$. 231 | \end{lemma} 232 | 233 | Let $m$ be a minimal element in $(From\_Sender(v, \sigma), \preceq)$. Then $m$ is a latest message iff $\{m \in From\_Sender(v, \sigma): Later\_From(m, v, \sigma) = \emptyset \}$ 234 | 235 | \begin{proof}(By Contradiction) 236 | Assume that a minimal element $m$ is not a latest message. 237 | \begin{align*} 238 | & \forall m' \in From\_Sender(v, \sigma), m \preceq m' \land m \notin L_M(\sigma)(v) 239 | \\ 240 | \Longleftrightarrow& \forall m' \in From\_Sender(v, \sigma), m \preceq m' \land m \notin \{m'' \in From\_Sender(v, \sigma): Later\_From(m'', v, \sigma) = \emptyset\} 241 | \\ 242 | \Longleftrightarrow& \forall m' \in From\_Sender(v, \sigma), m \preceq m' \land Later\_From(m, v, \sigma) \not = \emptyset 243 | \\ 244 | \Longleftrightarrow& \forall m' \in From\_Sender(v, \sigma), m \preceq m' \land \exists m^* \in Later\_From(m, v, \sigma) 245 | \\ 246 | \Longleftrightarrow& \forall m' \in From\_Sender(v, \sigma), m \preceq m' \land \exists m^* \in Later\_From(m, v, \sigma), m^* \in Later(m, \sigma) \cap From\_Sender(v, \sigma) 247 | \\ 248 | \Longleftrightarrow& \forall m' \in From\_Sender(v, \sigma), m \preceq m' \land \exists m^* \in Later\_From(m, v, \sigma), m^* \in Later(m, \sigma) 249 | \\ 250 | \Longleftrightarrow& \forall m' \in From\_Sender(v, \sigma), m \preceq m' \\ &\land \exists m^* \in Later\_From(m, v, \sigma), m^* \in Later(m, \sigma) \land m \in Justification(m^*) 251 | \\ 252 | \Longrightarrow& \forall m' \in From\_Sender(v, \sigma), m \preceq m' \\ &\land \exists m^* \in Later\_From(m, v, \sigma), Justification(m) \subseteq Justification(m^*) \land m \in Justification(m^*) 253 | \\ 254 | \Longrightarrow& \forall m' \in From\_Sender(v, \sigma), |Justification(m)| \geq |Justification(m'))| \\ &\land \exists m^* \in Later\_From(m, v, \sigma), Justification(m) \subseteq Justification(m^*) \land m \in Justification(m^*) 255 | \\ 256 | \Longrightarrow& \exists m^* \in Later\_From(m, v, \sigma), Justification(m) \subseteq Justification(m^*) \land m \in Justification(m^*) \\ &\land |Justification(m)| \geq |Justification(m^*)| 257 | \\ 258 | \Longrightarrow& \exists m^* \in Later\_From(m, v, \sigma), Justification(m) \subseteq Justification(m^*) \land \{m\} \subseteq Justification(m^*) \\ &\land |Justification(m)| \geq |Justification(m^*)| 259 | \\ 260 | \Longrightarrow& \exists m^* \in Later\_From(m, v, \sigma), Justification(m) \cup \{m\} \subseteq Justification(m^*) \\ &\land |Justification(m)| \geq |Justification(m^*)| 261 | \\ 262 | \Longrightarrow& \exists m^* \in Later\_From(m, v, \sigma), |Justification(m)| + |\{m\}| - |Justification(m) \cap \{m\}| \leq |Justification(m^*)| \\ &\land |Justification(m)| \geq |Justification(m^*)| 263 | \\ 264 | \Longrightarrow& \exists m^* \in Later\_From(m, v, \sigma), |Justification(m)| + |\{m\}| - |Justification(m) \cap \{m\}| \leq |Justification(m^*)| \\ &\land Justification(m) \cap \{m\} = \emptyset \land |Justification(m)| \geq |Justification(m^*)| 265 | \\ 266 | \Longrightarrow& \exists m^* \in Later\_From(m, v, \sigma), |Justification(m)| + |\{m\}| - |Justification(m) \cap \{m\}| \leq |Justification(m^*)| \\ &\land |Justification(m) \cap \{m\}| = 0 \land |Justification(m)| \geq |Justification(m^*)| 267 | \\ 268 | \Longrightarrow& \exists m^* \in Later\_From(m, v, \sigma), |Justification(m)| + |\{m\}| \leq |Justification(m^*)| \\ &\land |Justification(m)| \geq |Justification(m^*)| 269 | \\ 270 | \Longrightarrow& \exists m^* \in Later\_From(m, v, \sigma), |Justification(m)| + |\{m\}| \leq |Justification(m^*)| \land |\{m\}| \geq 1 \\ &\land |Justification(m)| \geq |Justification(m^*)| 271 | \end{align*} 272 | 273 | This leads to a contradiction in these three inequalities. Therefore, a minimal message in $From\_Sender(v, \sigma)$ is a latest message from validator $v$. 274 | \end{proof} 275 | 276 | \begin{lemma} 277 | There is at least one minimal element in $(From\_Sender(v, \sigma), \preceq)$ for a $v \in Observed(\sigma)$. 278 | \end{lemma} 279 | 280 | \begin{proof} 281 | \begin{align*} 282 | &v \in Observed(\sigma) 283 | \\ 284 | \Longrightarrow& v \in \{ Sender(m) : m \in \sigma \} 285 | \\ 286 | \Longrightarrow& \exists m \in \sigma, Sender(m) = v 287 | \\ 288 | \Longrightarrow& \exists m \in \{m \in \sigma: Sender(m) = v\} 289 | \\ 290 | \Longrightarrow& \exists m \in From\_Sender(v, \sigma) 291 | \\ 292 | \Longrightarrow& From\_Sender(v, \sigma) \not = \emptyset 293 | \end{align*} 294 | 295 | By Well-Ordering Principle, a non-empty countable total order always has a minimal element. 296 | \end{proof} 297 | 298 | Hence, observed validators have latest messages, i.e., $\forall \sigma \in \Sigma, \forall v \in \mathcal{V},\\ v \in Observed(\sigma) \implies |L_M(\sigma)(v)| \geq 1 299 | $ 300 | 301 | 302 | \begin{lemma}[Observed non-equivocating validators have one latest message] 303 | $\forall \sigma \in \Sigma, \forall v \in \mathcal{V}$ 304 | $$ 305 | v \in Observed(\sigma) \land v \notin E(\sigma) \implies |L_M(\sigma)(v)| = 1 306 | $$ 307 | \end{lemma} 308 | 309 | \begin{proof} 310 | \begin{align*} 311 | &v \in Observed(\sigma) \land v \notin E(\sigma) \\ 312 | &\implies |L_M(\sigma)(v)| \geq 1 \land |L_M(\sigma)(v)| \leq 1 \\ 313 | &\implies |L_M(\sigma)(v)| = 1 314 | \end{align*} 315 | \end{proof} 316 | 317 | \begin{defn}[Latest messages from non-Equivocating validators] 318 | $$ 319 | L^H_M:\Sigma \to (\mathcal{V} \to \mathcal{P}(M)) 320 | $$ 321 | \[ L^H_M(\sigma)(v) = \left\{ 322 | \begin{array}{ll} 323 | \emptyset& \text{ for } v \in E(\sigma) \\ 324 | L_M(\sigma)(v)& \text{ otherwise } 325 | \end{array} 326 | \right. \] 327 | \end{defn} 328 | 329 | Note that the map returned by this function has values $L^H_M(\sigma)(v) = \emptyset$ for any validators who are equivocating in $\sigma$ or who don't have any messages in $\sigma$. 330 | 331 | 332 | \begin{defn}[Latest honest message driven estimator] 333 | \begin{align*} 334 | Latest\_Honest\_Message\_Driven:& \mathcal{P}(C)^\Sigma \to \{True, False\} \\ 335 | Latest\_Honest\_Message\_Driven(\mathcal{E}) :\Leftrightarrow& \exists \hat{\mathcal{E}} \in \mathcal{P}(C)^{\mathcal{P}(M)^\mathcal{V}}, ~~\mathcal{E} = \hat{\mathcal{E}} \circ L^H_M 336 | \end{align*} 337 | \end{defn} 338 | 339 | 340 | \begin{defn}[Latest Estimates from non-Equivocating validators] 341 | $$ 342 | L^H_E:\Sigma \to (\mathcal{V} \to \mathcal{P}(\mathcal{C})) 343 | $$ 344 | $$ 345 | L^H_E(\sigma)(v) = \{Estimate(m) : m \in L^H_M(\sigma)(v)\} 346 | $$ 347 | \end{defn} 348 | 349 | As above, $L^H_E(\sigma)(v) = \emptyset$ for validators $v$ who are equivocating or missing in $\sigma$. 350 | 351 | \begin{defn}[Latest honest estimate driven estimator] 352 | \begin{align*} 353 | Latest\_Honest\_Estimate\_Driven:& \mathcal{P}(C)^\Sigma \to \{True, False\} \\ 354 | Latest\_Honest\_Estimate\_Driven(\mathcal{E}) :\Leftrightarrow& \exists \hat{\mathcal{E}} \in \mathcal{P}(C)^{\mathcal{P}(C)^\mathcal{V}}, ~~\mathcal{E} = \hat{\mathcal{E}} \circ L^H_E 355 | \end{align*} 356 | \end{defn} 357 | 358 | All the example protocols we will give will have latest honest estimate driven estimators. 359 | 360 | \iffalse 361 | We define ``!", an operator used to return the single element of a singleton set: 362 | \begin{defn} 363 | $$ 364 | !: \mathcal{P}(X) \to X 365 | $$ 366 | $$ 367 | !(A) = a \in A : \forall b \in A, b = a 368 | $$ 369 | \end{defn} 370 | 371 | Note that it is not defined when its argument is not singleton (i.e. when it is a multi-element or empty set). 372 | 373 | \begin{defn}[Properties of Consensus Values] 374 | \begin{align*} 375 | P_{\mathcal{C}} = \{True, False\}^{\mathcal{C}} 376 | \end{align*} 377 | \end{defn} 378 | \fi 379 | 380 | %--------------------------------------------------------------------------------------------------------------------- 381 | %--------------------------------------------------------------------------------------------------------------------- 382 | %--------------------------------------------------------------------------------------------------------------------- 383 | %--------------------------------------------------------------------------------------------------------------------- 384 | %--------------------------------------------------------------------------------------------------------------------- 385 | %--------------------------------------------------------------------------------------------------------------------- 386 | %--------------------------------------------------------------------------------------------------------------------- 387 | 388 | 389 | \subsection{Casper the Friendly Binary Consensus} 390 | 391 | \begin{defn}[Argmax] 392 | \begin{align*} 393 | Argmax &: \mathcal{P}(a) \times (a \to \mathbb{R}) \to \mathcal{P}(a) \\ 394 | Argmax(X, f) &= \{x \in X : \nexists x' \in X, f(x') > f(x)\} 395 | \end{align*} 396 | where $a$ is a type variable. 397 | \end{defn} 398 | 399 | For notational convenience, we may write $Argmax(X, f)$ as $\argmax\limits_{x \in X} f(x)$. 400 | 401 | 402 | \begin{defn}[Score] 403 | \begin{align*} 404 | Score &: \{0, 1\} \times \Sigma \to \mathbb{R} \\ 405 | Score(x, \sigma) &= \sum_{v \in V: x \in L^H_E(\sigma)(v)} \mathcal{W}(v) 406 | \end{align*} 407 | \end{defn} 408 | 409 | 410 | \begin{defn}[Casper the Friendly Binary Consensus] 411 | \begin{align*} 412 | \mathcal{C} &= \{0, 1\} \\ 413 | \mathcal{E}(\sigma) &= \argmax\limits_{c \in C} ~Score(c, \sigma) 414 | \end{align*} 415 | \end{defn} 416 | 417 | Which makes decisions on two properties, ``is 0" and ``is 1", which identify the consensus values. 418 | 419 | \begin{defn}[Example non-trivial properties of this binary consensus protocol] 420 | $$ 421 | P = \{p \in P_{\mathcal{C}} : \exists ! c \in C, p(c) = True\} 422 | $$ 423 | \end{defn} 424 | 425 | \iffalse 426 | 427 | \begin{thm} 428 | $\forall p \in P$, 429 | $$ 430 | Max\_Driven(p) 431 | $$ 432 | \end{thm} 433 | 434 | \begin{proof} 435 | We say that $p(i) = True \land p(1 - i) = False$ 436 | \begin{align*} 437 | &Weight(Agreeing(p, \sigma)) > Weight(Disagreeing(p, \sigma)) \\ 438 | &\implies Weight(\{v \in \mathcal{V} : \exists c \in L^H_E(\sigma)(v), p(c)\}) > Weight(\{v \in \mathcal{V} : \exists c \in L^H_E(\sigma)(v), \neg p(c)\}) \\ 439 | &\implies \sum_{v \in \mathcal{V} : \exists c \in L^H_E(\sigma)(v), p(c)} \mathcal{W}(v) > \sum_{v \in \mathcal{V} : \exists c \in L^H_E(\sigma)(v), \neg p(c)} \mathcal{W}(v) \\ 440 | &\implies \sum_{v \in \mathcal{V} : i \in L^H_E(\sigma)(v)} \mathcal{W}(v) > \sum_{v \in \mathcal{V} : 1-i \in L^H_E(\sigma)(v)} \mathcal{W}(v) \\ 441 | &\implies \mathcal{E}(\sigma) = \{i\} \\ 442 | &\implies \forall c \in \mathcal{E}(\sigma), p(c) \\ 443 | \end{align*} 444 | \end{proof} 445 | \fi 446 | 447 | 448 | \subsection{Casper the Friendly Integer Consensus} 449 | 450 | 451 | \iffalse 452 | \begin{defn}[Weight Less Than x] 453 | \begin{align*} 454 | WLX:& \mathbb{Z} \times \mathcal{P}_{fin}(\mathbb{Z}) \times (\mathbb{Z} \to \mathbb{R}) \to \mathbb{R} \\ 455 | WLX(x, X, W) =& \sum_{x' \in X : x' < x} W(x') 456 | \end{align*} 457 | \end{defn} 458 | 459 | \begin{defn}[Weight Greater Than x] 460 | \begin{align*} 461 | WLX:& \mathbb{Z} \times \mathcal{P}_{fin}(\mathbb{Z}) \times (\mathbb{Z} \to \mathbb{R}) \to \mathbb{R} \\ 462 | WGX(x, X, W) =& \sum_{x' \in X : x' > x} W(x') 463 | \end{align*} 464 | \end{defn} 465 | 466 | \begin{defn}[Weighted Median] 467 | \begin{align*} 468 | Median &: \mathcal{P}(\mathbb{Z}) \times (\mathbb{Z}\to \mathbb{R}) \to \mathcal{P}(\mathbb{Z}) \\ 469 | Median(X, W) &= \{x \in X : WLX(x, X, W) \leq \sum_{x' \in X} W(x')/2 \\ 470 | &~~~~~~~~~~~~~\land WGX(x, X, W) \leq \sum_{x' \in X} W(x')/2\} 471 | \end{align*} 472 | \end{defn} 473 | \fi 474 | 475 | \begin{defn}[Weighted Median] 476 | \begin{align*} 477 | Median &: \mathcal{P}(\mathbb{Z}) \times (\mathbb{Z}\to \mathbb{R}) \to \mathcal{P}(\mathbb{Z}) \\ 478 | Median(X, W) &= \{x \in X : \sum_{x' \in X : x' < x} W(x') \leq \sum_{x' \in X} W(x')/2 \\ 479 | &~~~~~~~~~~~~~\land \sum_{x' \in X : x' > x} W(x') \leq \sum_{x' \in X} W(x')/2\} 480 | \end{align*} 481 | \end{defn} 482 | 483 | \begin{defn}[Score] 484 | \begin{align*} 485 | Score &: \mathbb{Z} \times \Sigma \to \mathbb{R} \\ 486 | Score(x, \sigma) &= \sum_{v \in V: x \in L^H_E(\sigma)(v)} \mathcal{W}(v) 487 | \end{align*} 488 | \end{defn} 489 | 490 | 491 | \begin{defn}[Casper the Friendly Integer Consensus] 492 | \begin{align*} 493 | \mathcal{C} &= \mathbb{Z} \\ 494 | \mathcal{E}(\sigma) &= Median(\cup_{v \in \mathcal{V}} L^H_E(\sigma)(v), \lambda x. Score(x, \sigma)) 495 | \end{align*} 496 | 497 | \end{defn} 498 | 499 | \begin{defn}[Example non-trivial properties of the integer consensus protocol] 500 | $$ 501 | P = \{p \in P_{\mathcal{C}} : \exists! z \in \mathcal{C}, p(z) = True\} 502 | $$ 503 | \end{defn} 504 | 505 | 506 | 507 | \subsection{Casper the Friendly GHOST} 508 | 509 | Greedy Heaviest Observed Sub-Tree\cite{GHOST} is a contruction proposed to tackle reduced security issues in blockchains with fast confirmation times. Here, we present a CBC specification for a GHOST-based blockchain fork choice rule. 510 | 511 | Starting from a genesis block $g$, we can define all blocks in a blockchain to have a previous block and some block data $D$. 512 | 513 | \begin{defn}[Blocks] 514 | \begin{align*} 515 | B_0 &= \{g\} \\ 516 | B_n &= B_{n-1} \times D \\ 517 | B &= \bigcup_{i = 0}^{\infty} B_i 518 | \end{align*} 519 | \end{defn} 520 | 521 | Blocks/blockchains will be the consensus value for blockchain consensus. 522 | 523 | Every block in a blockchain has a single previous block. 524 | 525 | \begin{defn}[Previous block resolver] 526 | $$ 527 | Prev: B \to B 528 | $$ 529 | \[ Prev(b) = \begin{cases} 530 | g &\text{ if $b = g$ }\\ 531 | b' &\text{ otherwise, if $b = (b', d)$ }\\ 532 | \end{cases} 533 | \] 534 | \end{defn} 535 | 536 | \[ Prev(b) = \left\{ 537 | \begin{array}{ll} 538 | g& \text{ if $b = g$ } \\ 539 | Proj_1(b)& \text{ otherwise } 540 | \end{array} 541 | \right. \] 542 | 543 | 544 | \begin{defn}[n-cestor: n'th generation ancestor block] 545 | $$ 546 | n\text{-}cestor : B \times \mathbb{N} \to B\\ 547 | $$ 548 | \[ n\text{-}cestor(b, n) = \left\{ 549 | \begin{array}{ll} 550 | b& \text{ if $n = 0$ } \\ 551 | n\text{-}cestor(Prev(b), n - 1)& \text{ otherwise } 552 | \end{array} 553 | \right. \] 554 | \end{defn} 555 | 556 | 557 | A block is "in the blockchain" of another block if it is one of its ancestors. 558 | 559 | \begin{defn}[Blockchain membership, $m_1 \downharpoonright m_2$] 560 | \begin{align*} 561 | \cdot \downharpoonright \cdot&: B \times B \to \{True, False\} \\ 562 | b_1 \downharpoonright b_2 &:\Leftrightarrow \exists n \in \mathbb{N}, b_1 = n\text{-}cestor(b_2, n) 563 | \end{align*} 564 | \end{defn} 565 | 566 | We define the ``score'' of a block $b$ in state $\sigma$ as the total weight of validators with latest blocks $b'$ such that $b \downharpoonright b'$. 567 | 568 | \begin{defn}[Score of a block] 569 | \begin{align*} 570 | Score: M \times \Sigma &\to \mathbb{R} \\ 571 | Score(b, \sigma) &= \sum_{v \in \mathcal{V} : \exists b' \in L^H_E(\sigma)(v), b \downharpoonright b'} \mathcal{W}(v) 572 | \end{align*} 573 | \end{defn} 574 | 575 | 576 | The ``children'' of a block $b$ in a protocol state $\sigma$ are the blocks with $b$ as their previous block. 577 | 578 | \begin{defn} 579 | \begin{align*} 580 | Children&: M \times \Sigma \to \mathcal{P}(M)\\ 581 | Children(b,\sigma) &= \{b' \in \bigcup_{m \in \sigma} \{Estimate(m)\} : Prev(b') = b\} 582 | \end{align*} 583 | \end{defn} 584 | 585 | We now have the language required to define the estimator for the blockchain consensus, the Greedy Heaviest-Observed Sub-Tree fork choice rule, or GHOST! 586 | 587 | \begin{defn} 588 | \begin{align*} 589 | Best\_Children&: B \times \Sigma \to \mathcal{P}(B)\\ 590 | Best\_Children(b,\sigma) &= \argmax\limits_{b' \in Children(b, \sigma)} Score(b', \sigma) 591 | \end{align*} 592 | \end{defn} 593 | 594 | \begin{defn} 595 | \begin{align*} 596 | GHOST&: \mathcal{P}(B) \times \Sigma \to \mathcal{P}(B)\\ 597 | GHOST(\underline{b},\sigma) &= \bigcup\limits_{\substack{b \in \underline{b} ~:\\ Children(b, \sigma) \neq \emptyset}} GHOST(Best\_Children(b,\sigma), \sigma) \\ 598 | &~~~\cup \bigcup\limits_{\substack{b \in \underline{b} ~:\\ Children(b, \sigma) = \emptyset}} \{b\} 599 | \end{align*} 600 | \end{defn} 601 | 602 | 603 | \begin{defn}[Casper the Friendly Ghost] 604 | \begin{align*} 605 | \mathcal{C} &= B \\ 606 | \mathcal{E}(\sigma) &= GHOST(\{g\}, \sigma) 607 | \end{align*} 608 | \end{defn} 609 | 610 | \iffalse 611 | We can define GHOST differently. 612 | 613 | \begin{defn} 614 | \begin{align*} 615 | Chain&: B \to \mathcal{P}(B)\\ 616 | Chain(g) &= \{\} \\ 617 | Chain(b) &= \{b\} \cup Chain(Prev(b)) 618 | \end{align*} 619 | \end{defn} 620 | 621 | \begin{defn} 622 | \begin{align*} 623 | GHOST&: \Sigma \to \mathcal{P}(B)\\ 624 | GHOST(\sigma) &= \{b \in \sigma : Children(b, \sigma) = \emptyset \land \forall b' \in Chain(b), \forall b'' \in Children(Prev(b), \sigma), Score(b') \geq Score(b'')\} 625 | \end{align*} 626 | \end{defn} 627 | \fi 628 | 629 | 630 | \begin{defn}[Example non-trivial properties of consensus values] 631 | $$ 632 | P = \{p \in P_{\mathcal{C}} : \exists! b \in \mathcal{C}, \forall b' \in \mathcal{C}, (b \downharpoonright b' \implies p(b') = True) \land (\neg(b \downharpoonright b') \implies p(b') = False)\} 633 | $$ 634 | \end{defn} 635 | 636 | 637 | \iffalse 638 | \begin{thm} 639 | $\forall p \in P$, 640 | $$ 641 | Max\_Weight(p) 642 | $$ 643 | \end{thm} 644 | \fi 645 | 646 | 647 | 648 | \subsection{Casper the Friendly CBC Finality Gadget} 649 | 650 | Finality gadgets are consensus protocols on the blocks of an underlying blockchain, which has its own block structure and fork choice rule. Casper the Friendly Finality Gadget\cite{vitalik2017casperffg} describes one such construction of a finality gadget. 651 | 652 | Here, we will describe the underlying blockchain and the conditions it must satisfy, before showing how to layer a CBC Casper finality gadget on top, namely in the form of a change to the blockchain's forkchoice. 653 | 654 | \begin{defn}[The underlying blockchain] 655 | We assume the blockchain has blocks: 656 | 657 | 658 | Starting from a genesis block $g$, we can define all blocks in a blockchain to have a previous block and some block data $D$. 659 | 660 | \begin{defn}[Blocks] 661 | \begin{align*} 662 | B_0 &= \{g\} \\ 663 | B_n &= B_{n-1} \times D \\ 664 | B &= \bigcup_{i = 0}^{\infty} B_i 665 | \end{align*} 666 | \end{defn} 667 | 668 | Blocks/blockchains will be the consensus value for blockchain consensus. 669 | 670 | Every block in a blockchain has a single previous block. 671 | 672 | \begin{defn}[Previous block resolver] 673 | $$ 674 | Prev: B \to B 675 | $$ 676 | \[ Prev(b) = \begin{cases} 677 | g &\text{ if $b = g$ }\\ 678 | b' &\text{ otherwise, if $b = (b', d)$ }\\ 679 | \end{cases} 680 | \] 681 | \end{defn} 682 | 683 | \[ Prev(b) = \left\{ 684 | \begin{array}{ll} 685 | g& \text{ if $b = g$ } \\ 686 | Proj_1(b)& \text{ otherwise } 687 | \end{array} 688 | \right. \] 689 | 690 | 691 | \begin{defn}[n-cestor: n'th generation ancestor block] 692 | $$ 693 | n\text{-}cestor : B \times \mathbb{N} \to B\\ 694 | $$ 695 | \[ n\text{-}cestor(b, n) = \left\{ 696 | \begin{array}{ll} 697 | b& \text{ if $n = 0$ } \\ 698 | n\text{-}cestor(Prev(b), n - 1)& \text{ otherwise } 699 | \end{array} 700 | \right. \] 701 | \end{defn} 702 | 703 | 704 | A block is "in the blockchain" of another block if it is one of its ancestors. 705 | 706 | \begin{defn}[Blockchain membership, $m_1 \downharpoonright m_2$] 707 | \begin{align*} 708 | \cdot \downharpoonright \cdot&: B \times B \to \{True, False\} \\ 709 | b_1 \downharpoonright b_2 &:\Leftrightarrow \exists n \in \mathbb{N}, b_1 = n\text{-}cestor(b_2, n) 710 | \end{align*} 711 | \end{defn} 712 | 713 | We note that $\forall b \in B, g \downharpoonright b$. 714 | 715 | The blockchain is also equipped with a height map that satisfies the following conditions: 716 | \begin{align*} 717 | Height&: B \to \mathbb{N} \\ 718 | Height(b) &= \begin{cases} 719 | \text{$0$} &\text{if $b = g$} \\ 720 | \text{$1 + Height(Prev(b))$} &\text{otherwise} 721 | \end{cases} 722 | \end{align*} 723 | 724 | Finally, the underlying blockchain has a forkchoice rule, which is parametric in a starting block (where the forkchoice ``begins"): 725 | $$ 726 | \mathcal{F}: B \times \mathcal{P}(B) \to B 727 | $$ 728 | 729 | The forkchoice returns a block ``on top of" the starting block: 730 | $$ 731 | \forall b \in B, \forall \underline{B} \in \mathcal{P}(B), b \downharpoonright \mathcal{F}(b, \underline{B}) 732 | $$ 733 | \end{defn} 734 | 735 | We can now construct the consensus values for the finality gadget. 736 | \begin{defn}[Consensus values in the CBC Finality Gadget] 737 | Finality gadgets specify 'epoch lengths,' which is essentially how frequently they operate: 738 | $$ 739 | Epoch\_Length \in \mathbb{N}_+ 740 | $$ 741 | The consensus values are blocks on the epoch boundries: 742 | $$ 743 | \mathcal{C} = \{b \in B : Height(b) \equiv 0 \pmod{Epoch\_Length}\} 744 | % maybe change to divides relation? 745 | % AA: congruence FTW 746 | $$ 747 | \end{defn} 748 | 749 | We now construct the finality gadgets new forkchoice, which can be understood as GHOST on the epochs, followed by the underlying blockchain's forkchoice from the tip epoch. 750 | 751 | As $\mathcal{C}$ is a subset of $B$, we can inherit the blockchain membership relation $\downharpoonright$ from $B$. 752 | % \begin{defn}[Blockchain Epoch membership, $m_1 \downharpoonright_c m_2$] 753 | % \begin{align*} 754 | % \cdot \downharpoonright_c \cdot&: C \times B \to \{True, False\} \\ 755 | % b_1 \downharpoonright_c b_2 &:\Leftrightarrow \exists n \in \mathbb{N}, b_1 = n\text{-}cestor(b_2, n) \land n \equiv 0 \pmod{Epoch\_Length} 756 | % \end{align*} 757 | % \end{defn} 758 | 759 | This allows us to define the score of an epoch. 760 | \begin{defn}[Epoch Score] 761 | \begin{align*} 762 | Epoch\_Score&: \mathcal{C} \times \Sigma \to \mathbb{R} \\ 763 | Epoch\_Score(e, \sigma) &= \sum_{v \in \mathcal{V} : \exists b' \in L^H_E(\sigma)(v), e \downharpoonright b'} \mathcal{W}(v) 764 | \end{align*} 765 | \end{defn} 766 | 767 | \begin{defn}[Children Epochs] 768 | % \begin{align*} 769 | % Children\_Epochs&: \mathcal{C} \times \mathcal{P}(B) \to \mathcal{C} \\ 770 | % Children\_Epochs(e, bs) &= \{b' \in bs: e \downharpoonright b' \land Height(b') = Height(e) + Epoch\_Length\} 771 | % \end{align*} 772 | \begin{align*} 773 | Children\_Epochs&: \mathcal{C} \times \Sigma \to \mathcal{C} \\ 774 | Children\_Epochs(e, \sigma) &= \{b' \in Blocks\_In(\sigma): e \downharpoonright b' \land Height(b') = Height(e) + Epoch\_Length\} 775 | \end{align*} 776 | \end{defn} 777 | 778 | % Note that while the score of an epoch is parametric in protocol states $\sigma \in \Sigma$, the children epochs are parametric in a set of blocks $bs \subset B$. Notably, for sets of blocks, we assume that the forkchoice runner has seen a set of blocks in the underlying blockchain satisfying the condition $bs \subset B : b \in bs \implies Prev(b) \in bs$. 779 | 780 | % We can now define the best children epochs, given a protocol state and the blocks the forkchoice runner has seen: 781 | \begin{defn} 782 | % \begin{align*} 783 | % Best\_Children\_Epochs&: C \times \mathcal{P}(B) \times \Sigma \to \mathcal{P}(C)\\ 784 | % Best\_Children\_Epochs(e, bs, \sigma) &= \argmax\limits_{e' \in Children\_Epochs(e, bs)} Epoch\_Score(e', \sigma) 785 | % \end{align*} 786 | \begin{align*} 787 | Best\_Children\_Epochs&: C \times \Sigma \to \mathcal{P}(C)\\ 788 | Best\_Children\_Epochs(e, \sigma) &= \argmax\limits_{e' \in Children\_Epochs(e, \sigma)} Epoch\_Score(e', \sigma) 789 | \end{align*} 790 | \end{defn} 791 | 792 | We can now define GHOST on the epochs: 793 | 794 | \begin{defn} 795 | \begin{align*} 796 | GHOST&: \mathcal{P}(C) \times \Sigma \to \mathcal{P}(B)\\ 797 | GHOST(\underline{b}, \sigma) &= [ \bigcup\limits_{\substack{\underline{b} \in \underline{b} \\ Children\_Epochs(b, \sigma) \neq \emptyset}} GHOST(Best\_Children\_Epochs(b, \sigma), \sigma) ] \\ 798 | &~~~\cup [ \bigcup\limits_{\substack{b \in \underline{b} \\ Children\_Epochs(b, \sigma) = \emptyset}} \{b\} ] 799 | \end{align*} 800 | \end{defn} 801 | 802 | % \begin{defn}[Estimator for the CBC Finality gadget] 803 | % $$ 804 | % \mathcal{E}_{\underline{b}}(\sigma) = \{ b \in \underline{b} \cap C: \exists b' \in \bigcup_{e \in GHOST(\{g\}, \underline{b}, \sigma)} \mathcal{F}(e, \underline{b}) ~,~~ n\text{-}cestor(b',Height(b) \pmod{Epoch\_Length}) = b \} 805 | % $$ 806 | 807 | % \end{defn} 808 | 809 | \begin{defn}[Estimator for the CBC Finality gadget] 810 | 811 | $$ 812 | \mathcal{E}(\sigma) = \{ b \in \mathcal{C}: \exists b' \in GHOST(\{g\}, \sigma), b' \downharpoonright b \} 813 | $$ 814 | 815 | \end{defn} 816 | 817 | \begin{defn}[Fork Choice Rule for the CBC Finality gadget] 818 | Original fork choice rule: 819 | $$ 820 | \mathcal{F}(\{g\}, \underline{b}) 821 | $$ 822 | 823 | New fork choice rule: 824 | $$ 825 | \mathcal{F}(\mathcal{E}(\sigma), \underline{b})) 826 | $$ 827 | 828 | \end{defn} 829 | 830 | Finally, we now insist that the forkchoice rule of the underlying chain starts at the estimator of the finality gadget, completing our definition of the underlying blockchain protocol. 831 | 832 | 833 | \subsection{Casper the Friendly CBC Sharded Blockchain} 834 | 835 | \begin{defn}[Shard IDs $S$] 836 | \begin{align*} 837 | S 838 | \end{align*} 839 | \end{defn} 840 | 841 | \begin{defn}[Message Payloads $P$] 842 | \begin{align*} 843 | P 844 | \end{align*} 845 | \end{defn} 846 | 847 | \begin{defn}[Block Data $D$] 848 | \begin{align*} 849 | D 850 | \end{align*} 851 | \end{defn} 852 | 853 | \begin{defn}[Lists of Things] 854 | For a set $X$, let $X^*$ denote all the finite length lists of elements in set $X$. 855 | \end{defn} 856 | 857 | \begin{defn}[List Prefix $\preceq$] 858 | $A \preceq B$ iff list $A$ is a prefix of list $B$ 859 | \end{defn} 860 | 861 | \newcommand{\Q}{B \times \mathbb{N} \times P} 862 | 863 | We note that the blocks we will construct for the sharded blockchain satisfy this equation: 864 | $$ 865 | B \subseteq S \times B \times (S \to (\Q)^*) \times (S \to (\Q)^*) \times (S \to B \cup \{\emptyset\}) \times D 866 | $$ 867 | 868 | which allows us to define the following convenience functions: 869 | 870 | \begin{defn}[Blocks $B$] 871 | \begin{align*} 872 | \text{If } b = (shard\_id,~ prev\_blk, ~sent\_log,& ~recv\_log, ~src, ~blk\_data) \in B \text{ , then}\\ 873 | Shard(b) &= shard\_id \\ 874 | Prev(b) &= prev\_blk \\ 875 | Sent\_Log(b) &= sent\_log \\ 876 | Received\_Log(b) &= recv\_log \\ 877 | Source(b) &= src 878 | \end{align*} 879 | \end{defn} 880 | 881 | %TODO: I think the cross shard messages are not a subset of but instead equal B \times ... maybe. 882 | 883 | \begin{defn}[Cross-shard Messages $Q$] 884 | \begin{align*} 885 | Q \subseteq B \times \mathbb{N} \times& P \\ 886 | \text{If } (b, n, d) \in Q &\text{ , then:} \\ 887 | Base((b, n, d)) &= b \\ 888 | TTL((b, n, d)) &= n 889 | \end{align*} 890 | \end{defn} 891 | 892 | % TODO: why do we have these? Let's remove them. They complicate the spec for little benefit, I think. We can just note above (when introducing lists) that [] is the empty list 893 | 894 | \begin{defn}[Genesis Logs] 895 | \begin{align*} 896 | Log_g&: S \to (\Q)^* \\ 897 | \forall s \in S&, Log_g(s) = [] 898 | \end{align*} 899 | \end{defn} 900 | 901 | \begin{defn}[Genesis Sources] 902 | \begin{align*} 903 | Sources_g&: (S \to (\Q)^*) \times (S \to B \cup \{\emptyset\}) \\ 904 | \forall s \in S&, Sources_g(s) = \emptyset 905 | \end{align*} 906 | \end{defn} 907 | 908 | \subsubsection{Block Validity Conditions} 909 | 910 | We now introduce further restrictions on blocks, in the form of validity conditions. As these are functions on single blocks, we note that the type signature of these conditions is $B \to \{True, False\}$. 911 | 912 | \begin{defn}[Shard ID Consistency] 913 | \begin{align*} 914 | Shard\_ID\_Consistency(b) :\Leftrightarrow& Shard(Prev(b)) = Shard(b) \land \\ 915 | & \forall s \in S, \big[Shard(Sources(b)(s)) = s \\ 916 | &~~~~~~~~~~~ \land \forall q \in Sent\_Log(b)(s), Shard(Base(q)) = s \\ 917 | &~~~~~~~~~~~ \land \forall q \in Received\_Log(b)(s), Shard(Base(q)) = Shard(b) \big] 918 | \end{align*} 919 | \end{defn} 920 | 921 | \begin{defn}[Monotonicity Conditions] 922 | 923 | \textbf{ \\Monotonic Sources} 924 | \begin{align*} 925 | Source\_Monotonicity(b) :\Leftrightarrow& \forall s \in S, Source(b)(s) \downharpoonright Source(Prev(b))(s) 926 | \end{align*} 927 | 928 | \textbf{Sent Log Monotonicity} 929 | \begin{align*} 930 | Sent\_Log\_Monotonicity(b): \Leftrightarrow& \forall s \in S, Sent\_Log(Prev(b))(s) \preceq Sent\_Log(b)(s) 931 | \end{align*} 932 | 933 | \textbf{Receive Log Monotonicity} 934 | \begin{align*} 935 | Received\_Log\_Monotonicity(b): \Leftrightarrow& \forall s \in S, Received\_Log(Prev(b))(s) \preceq Received\_Log(b)(s) 936 | \end{align*} 937 | 938 | \textbf{Monotonic Bases} 939 | \begin{align*} 940 | Monotonic\_Sent\_Bases(b): \Leftrightarrow& \forall s \in S, \forall i \in [2, Length(Sent\_Log(b)(s))], \\ 941 | &~~~~~~~~~~~ Base(Sent\_Log(b)(s)[i-1]) \downharpoonright Base(Sent\_Log(b)(s)[i]) \\ 942 | Monotonic\_Received\_Bases(b): \Leftrightarrow& \forall s \in S, \forall i \in [2, Length(Received\_Log(b)(s))], \\ 943 | &~~~~~~~~~~~ Base(Received\_Log(b)(s)[i-1]) \downharpoonright Base(Received\_Log(b)(s)[i]) 944 | \end{align*} 945 | 946 | \textbf{Base-Source Monotonicity} 947 | \begin{align*} 948 | Base\_Source\_Monotonicity(b): \Leftrightarrow& \forall s \in S, \forall q \in Sent\_Log(b)(s), Source(b)(s) \downharpoonright Base(q) 949 | \end{align*} 950 | \end{defn} 951 | 952 | \begin{defn}[Messsage Arrival Conditions] 953 | 954 | \textbf{ \\Messages Sent by Source are Received Once and In-Order} 955 | \begin{align*} 956 | Receive\_Once\_In\_Order(b) :\Leftrightarrow& \forall s \in S, Received\_Log(b)(s) \preceq Sent\_Log(Source(b)(s))(Shard(b)) 957 | \end{align*} 958 | 959 | \textbf{Receive Messages by Expiry} 960 | \begin{align*} 961 | Receive\_By\_Expiry(b): \Leftrightarrow& \forall s \in S, \forall q \in Received\_Log(b)(s), \\ 962 | &~~~~~~~~~~~ Base(q) \downharpoonright b \land Height(b) - Height(Base(q)) \leq TTL(q) 963 | \end{align*} 964 | 965 | \textbf{Messages Sent but Not Received are Not Expired} \\ 966 | \begin{align*} 967 | Unreceived\_Messages\_Unexpired(b): \Leftrightarrow& \forall s \in S, \forall q \in Sent\_Log(b)(s) - Received\_Log(Source(b)(s))(Shard(b)), \\ 968 | &~~~~~~~~~~~ Height(Source(b)(s)) - Height(Base(q)) < TTL(q) 969 | \end{align*} 970 | \end{defn} 971 | 972 | We now have enouch structure to define the blocks in a sharded blockchain. 973 | 974 | \subsubsection{Blocks} 975 | \begin{defn}[Set of Blocks $B$] 976 | \begin{align*} 977 | B^0&= \bigcup_{i \in S} (i \times \{ \emptyset \} \times Log_g \times ( Log_g \times Received\_Sources_g ) \times Genesis\_Data) \\ 978 | B^n&= \Big\{ b \in S \times B^{n-1} \times (S \to (B^{n-1} \times \mathbb{N} \times P)^*) \times [(S \to (B^{n-1} \times \mathbb{N} \times P)^*) \times (S \to B^{n-1} \cup \{\emptyset\})] \times D : 979 | \\ 980 | % -------------------------------------------------------- 981 | % Shard ID validity conditions 982 | &~~~~~~~~~~~~~~~~ Shard\_ID\_Consistency(b) ~\land \\ 983 | &~~~~~~~~~~~~~~~~\big[Source\_Monotonicity(b) \\ 984 | &~~~~~~~~~~~~~~~~~ \land Sent\_Log\_Monotonicity(b) \\ 985 | &~~~~~~~~~~~~~~~~~ \land Received\_Log\_Monotonicity(b) \\ 986 | &~~~~~~~~~~~~~~~~~ \land Monotonic\_Sent\_Bases(b) \\ 987 | &~~~~~~~~~~~~~~~~~ \land Monotonic\_Received\_Bases(b)\\ 988 | &~~~~~~~~~~~~~~~~~ \land Base\_Source\_Monotonicity(b) \big] ~\land \\ 989 | &~~~~~~~~~~~~~~~~\big[Receive\_Once\_In\_Order(b) \\ 990 | &~~~~~~~~~~~~~~~~~ \land Receive\_By\_Expiry(b) \\ 991 | &~~~~~~~~~~~~~~~~~ \land Unreceived\_Messages\_Unexpired(b) \big] \\ 992 | \Big\} \\ 993 | B &= \bigcup_{n=0}^\infty B^n 994 | \end{align*} 995 | \end{defn} 996 | 997 | 998 | So we have the following consensus values 999 | \begin{defn}[Consensus values] 1000 | $$ 1001 | \mathcal{C} = B 1002 | $$ 1003 | \end{defn} 1004 | 1005 | \subsubsection{Estimator} 1006 | 1007 | \iffalse 1008 | Let us assume for now that we have an assignment of parent shards for each shard in $S$. Only the root shard has its parent as $\emptyset$. 1009 | \begin{defn}[Parent] 1010 | \begin{align*} 1011 | Parent&: S \to S \cup \{ \emptyset \} 1012 | \end{align*} 1013 | \end{defn} 1014 | \fi 1015 | 1016 | For this presentation we will assume that we have two shards $S= \{P, C\}$, where $P$ is the ``parent" (or root) shard and $C$ is the ``child" shard. The ``child"'s estimates will ``follow" the parents. The parent shard's fork choice rule is independent of the child's, and is (as an example for the sake of this presentation) simply GHOST: 1017 | 1018 | \begin{defn}[Fork Choice $\mathcal{E}_P$ (for root shard)] 1019 | \begin{align*} 1020 | \mathcal{E}_P&: \Sigma \to B \\ 1021 | \mathcal{E}_P&(\sigma) = GHOST(\{g_P\}, \sigma) 1022 | \end{align*} 1023 | \end{defn} 1024 | 1025 | The forkchoice of the parent ``restricts'' the fork choices that are allowed for the child shard. Through this restriction, fork choices on the parent and child shard will be ``synchronized", in that they won't have sources that disagree with blocks chosen on other shards, and there won't be any expired unreceived messages from the point of view of the blocks returned by the fork choice. 1026 | 1027 | To maintain these conditions, we introduce 4 ``filter conditions", which is a condition that will be used to prevent blocks that don't synchronize with the parent fork choice to be chosen in the child's fork choice. The condition is defined to be parametric in a block from the parent shard $b_P$. 1028 | 1029 | \begin{defn}[Filter Conditions] 1030 | \textbf{\\Parent to Child Source Block Consistency} 1031 | \begin{align*} 1032 | Filter_1(b_C; b_P): \Leftrightarrow& Source(b_P)(C) \cancel{\downharpoonright} b_C \\ 1033 | \end{align*} 1034 | \textbf{\\Child to Parent Source Block Consistency} 1035 | \begin{align*} 1036 | Filter_2(b_C; b_P): \Leftrightarrow& Source(b_C)(P) \cancel{\downharpoonright} b_P \\ 1037 | \end{align*} 1038 | We note that the relation $\downarrow$ holds for two blocks $b, b'$ if $b \downharpoonright b' \lor b' \downharpoonright b$ 1039 | \textbf{\\Parent to Child Sent Message Expiry Condition} 1040 | \begin{align*} 1041 | Filter_3(b_C; b_P): \Leftrightarrow& \exists q \in Sent\_Log(b_P)(C), q \notin Received\_Log(b_C)(P) \land Height(Base(q)) + TTL(q) \leq Height(b_C) \\ 1042 | \end{align*} 1043 | \textbf{Child to Parent Sent Message Expiry Condition} 1044 | \begin{align*} 1045 | Filter_4(b_C; b_P): \Leftrightarrow& \exists q \in Sent\_Log(b_C)(P), q \notin Received\_Log(b_P)(C) \land Height(Base(q)) + TTL(q) \leq Height(b_P) \\ 1046 | \end{align*} 1047 | \textbf{Total Filter} 1048 | \begin{align*} 1049 | Filter\_Block(b_C; b_P): \Leftrightarrow& Filter_1(b_C; b_P) \lor Filter_2(b_C; b_PC) \lor Filter_3(b_C; b_P) \lor Filter_4(b_C; b_P) \\ 1050 | \end{align*} 1051 | \end{defn} 1052 | 1053 | 1054 | \begin{defn}[Filtered Children] 1055 | \begin{align*} 1056 | Filtered\_Children&: B \times \mathcal{P}(B) \times ( B \to \{True, False\} ) \to \mathcal{P}(B) \\ 1057 | Filtered\_Children&(b, blocks, filter\_block) = \{ b' \in blocks: Prev(b') = b \land \neg Filter\_Block(b'; filter\_block) \} 1058 | \end{align*} 1059 | \end{defn} 1060 | 1061 | \begin{defn}[Best Child] 1062 | \begin{align*} 1063 | Best\_Children&: B \times \mathcal{P}(B) \times (B \to \mathbb{R}) \times B \to \mathcal{P}(B) \\ 1064 | Best\_Children&(b, blocks, W, filter\_block) = \argmax\limits_{b' \in Filtered\_Children(b, blocks, filter\_block)} W(b') 1065 | \end{align*} 1066 | \end{defn} 1067 | 1068 | \begin{defn}[Block score] 1069 | \begin{align*} 1070 | Score&: \Sigma \to (B \to \mathbb{R}^+) \\ 1071 | Score&(\sigma)(b) = \sum_{v \in \mathcal{V} : \exists b' \in L^H_E(\sigma)(v), b \downharpoonright b'} \mathcal{W}(v) 1072 | \end{align*} 1073 | \end{defn} 1074 | 1075 | We note that this score function works properly when each validator is assigned to a specific shard. In the future, this score function will count the score with respect to the latest honest messages on a specific shard. 1076 | 1077 | \begin{defn} 1078 | \begin{align*} 1079 | &Filtered\_GHOST: \mathcal{P}(B) \times \mathcal{P}(B) \times (B \to \mathbb{R}) \times B \to \mathcal{P}(B) \\ 1080 | &Filtered\_GHOST(\underline{b}, blocks, W, filter\_block) = \\ 1081 | &\bigcup\limits_{\substack{b \in \underline{b} ~:\\ Best\_Children(b, blocks, W, filter\_block) \neq \emptyset}} Filtered\_GHOST(Best\_Children(b, blocks, W, filter\_block), blocks, W, filter\_block)~ \cup \\ 1082 | &\bigcup\limits_{\substack{b \in \underline{b} ~:\\ Best\_Children(b, blocks, W, filter\_block) = \emptyset}} \{b\} 1083 | \end{align*} 1084 | \end{defn} 1085 | 1086 | Now, we can finially construct the forkchoice of the child, which can be understood as GHOST run from the source block on the child, where any blocks that satisfy the filter conditions are not chosen by GHOST. 1087 | 1088 | \begin{defn}[Fork Choice $\mathcal{E}_C$ (for child shard $C$)] 1089 | \begin{align*} 1090 | \mathcal{E}_C&: \Sigma \to \mathcal{P}(B) \\ 1091 | \mathcal{E}_C(\sigma) &= Filtered\_GHOST(\{Source({E}_P(\sigma))(C)\}, Blocks(\sigma), Score(\sigma), {E}_P(\sigma)) 1092 | \end{align*} 1093 | \end{defn} 1094 | 1095 | The estimator for the CBC sharded blockchain consensus protocol gives fork choices for both the parent and the child: 1096 | 1097 | \begin{defn}[Estimator $\mathcal{E}$] 1098 | \begin{align*} 1099 | \mathcal{E}_C&: \Sigma \to \mathcal{P}(B) \\ 1100 | \mathcal{E}(\sigma) &= {E}_P(\sigma) \cup {E}_C(\sigma) 1101 | \end{align*} 1102 | \end{defn} 1103 | --------------------------------------------------------------------------------