Използване на код срещу случайна честота

Една от най-гнусните, критични за консенсус грешки (CVE-2018–17144) беше открита наскоро в софтуера Bitcoin Core, който преди това имаше почти непорочна история. Jimmy Song е написал отлична разбивка на този бъг.

Краткото обобщение на грешката е, че има 4 случая, при които софтуерът Bitcoin Core трябва да провери за двойно изразходване. Всички 4 случая първоначално споделят един и същ поток на изпълнение на код. След някои фини итерации на кода в продължение на няколко години, един от 4-те случая („единичен tx-двойно изразходване-в-блок“) е пропуснат, което ще позволи на миньор потенциално да подмами някои възли да приеме блок което надува предлагането на биткойн.

Естеството на тази грешка ми напомня за постоянния конфликт между:

а) необходимостта от повторно използване и оптимизация на кода

(б) опасността да попадна заради това, което наричам случайна честота: неща, които са подобни не по дизайн, а случайно

Случайната честота създава плодородна почва за рефакторинг на кошмари и потенциални бъгове като CVE-2018–17144.

Случайна честота

Някакъв фон, ако не сте запознати със софтуерното инженерство:
 
В софтуера има тази велика визия на софтуерните компоненти да са перфектно модулни - подобно на техните технически колеги. Има добра причина да не е нужно да носите различен тип зарядно или USB проводник навсякъде, където отивате.

Така че винаги е имало силен тласък за повторно използване на кода. Писането на излишен код често е намръщено. Защо една и съща работа два пъти, когато можете да го направите веднъж?

Има и дълга история на преоткриване на колелото в софтуера, който дава повторно използване на кода дори по-висок приоритет в списъка с приоритети. Използването на код често се счита за една от най-добрите практики в отрасъла. Един амбициозен младши разработчик на софтуер може да е склонен да смята, че има нулев недостатък на повторно използване на кода.

Но има скрита опасност - и не вярвам, че тези неща се преподават правилно в училищата - от изключително използване на кодове.

Изключителна повторна употреба на кода означава свиване на всякакви две подобни на вид кодове в едно, независимо от случаите на тяхното използване и първоначалното намерение.

Който много пъти завършва с код, който има случайност.

Може да не е очевидно защо случайната честота е лоша, но човек трябва само да поддържа достатъчно голям софтуерен проект за дълъг период, за да разбере защо.

Лошо е, защото изискванията към продукта се променят и софтуерът е непрекъснато развиващ се, никога не напълно завършен продукт.

Този проблем с постоянна подвижна цел е нещо доста уникално за софтуера. Ако сте строителен инженер, не се очаква да превърнете къща в 20-етажна сграда или кола в летяща чиния. И все пак в софтуера ние постоянно правим това.

Когато изискванията на продукта и случаите на използване се променят, основните предположения, за които софтуерът е бил първоначално написан, може вече да не са приложими.

Така че гордото парче от общ код, което реконструирахте (но сега напълно сте забравили), вече не работи така, както смятате.

Загубих броя на болезнените рефакторинг проекти или гадни грешки, които видях, че са пряк резултат от преждевременна оптимизация или случайна честота - до момента, в който сега избягвам неща като Наследяването като чума.

Нещата, които имат случайност, бързо ще разкрият разликите си, когато те се развият извън първоначалното си състояние. Всяка твърдост в честотата на кода би била масивна бана, за да се отървете от нея.

Колкото повече слоеве на случайност има в кода, толкова повече е минно поле за навигация. CVE-2018–17144 е перфектен пример за това.