【Блокчейн-ритм】Один технічний фахівець поділився цікавою темою — у чому різниця між смарт-контрактами в системі облікових записів і у публічних ланцюгах.
Говорячи просто, обидва по суті одне й те саме: код, який автоматично виконується після виконання певних умов. Але тут є ключова різниця — питання повної тьюрінг-завершеності.
Смарт-контракти на публічних ланцюгах (наприклад, написані на Solidity) є повністю тьюрінг-завершеними, вони можуть робити все. А смарт-контракти у системі облікових записів — це обмежена тьюрінг-завершеність. Як вони обмежені? Програмування строго обмежене набором дозволених шаблонних скриптів, підтримуються лише ті, що заздалегідь визначені, з досить простими умовами тригера.
Чому так зроблено? З міркувань безпеки, ризик-менеджменту. Ця структура має працювати в межах фінансової системи, не можна, як у публічних ланцюгах, дозволити їй рости і розвиватися безконтрольно.
Цікаво, що з чисто технічної точки зору, розробляти ці контракти мовами з повною тьюрінг-завершеністю, наприклад Solidity, зовсім не складно — багато мов програмування це підтримують. Але справжня проблема в іншому: як розробити набір стандартних правил і механізмів аудиту, які б приймалися всією фінансовою системою. Це і є головне виклик.
Загалом, технічна база вже є, головне — баланс між системним дизайном і управлінням ризиками.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
10 лайків
Нагородити
10
6
Репост
Поділіться
Прокоментувати
0/400
SerRugResistant
· 6год тому
По суті, це старий компроміс між безпекою та свободою, нічого нового.
Переглянути оригіналвідповісти на0
GasWrangler
· 6год тому
Технічно кажучи, обмежена повнота Тюрінга — це насправді просто театральність безпеки, що маскується під інновації... якщо проаналізувати дані, системи на основі облікових записів — це просто компроміс між гнучкістю торгів і перевірками відповідності. на мою думку, це субоптимальний компроміс
Переглянути оригіналвідповісти на0
GlueGuy
· 6год тому
Знову почали боротьбу між повною Тьюріновою повнотою, по суті — один прагне свободи, інший — контролю.
Переглянути оригіналвідповісти на0
PerpetualLonger
· 6год тому
Братане, тепер я зрозумів: обмежена Тьюрінова повнота — це по суті фінансова система, яка накладає обмеження на код у ланцюгу. Публічний ланцюг вільний, але ризики вибухають; система облікових записів безпечна, але обмежена у можливостях. Зараз я тримаю всю позицію у смарт-контрактах публічних ланцюгів — це моя ставка на повний прорив у подоланні регулювань, віра.
Переглянути оригіналвідповісти на0
SighingCashier
· 6год тому
Ха, знову старий ідіоматичний приклад з Тьюріном, тут накладаю на себе кайдани
Обмеження — обмеження, принаймні можу спати спокійно, не турбуючись щодня, що контракт може зірватися
Переглянути оригіналвідповісти на0
MetamaskMechanic
· 6год тому
Тюринова повнота була обмежена, і це — ціна централізації
Система облікових записів смарт-контрактів vs публічні ланцюги контрактів: технічний баланс між тьюрінг-повнотою
【Блокчейн-ритм】Один технічний фахівець поділився цікавою темою — у чому різниця між смарт-контрактами в системі облікових записів і у публічних ланцюгах.
Говорячи просто, обидва по суті одне й те саме: код, який автоматично виконується після виконання певних умов. Але тут є ключова різниця — питання повної тьюрінг-завершеності.
Смарт-контракти на публічних ланцюгах (наприклад, написані на Solidity) є повністю тьюрінг-завершеними, вони можуть робити все. А смарт-контракти у системі облікових записів — це обмежена тьюрінг-завершеність. Як вони обмежені? Програмування строго обмежене набором дозволених шаблонних скриптів, підтримуються лише ті, що заздалегідь визначені, з досить простими умовами тригера.
Чому так зроблено? З міркувань безпеки, ризик-менеджменту. Ця структура має працювати в межах фінансової системи, не можна, як у публічних ланцюгах, дозволити їй рости і розвиватися безконтрольно.
Цікаво, що з чисто технічної точки зору, розробляти ці контракти мовами з повною тьюрінг-завершеністю, наприклад Solidity, зовсім не складно — багато мов програмування це підтримують. Але справжня проблема в іншому: як розробити набір стандартних правил і механізмів аудиту, які б приймалися всією фінансовою системою. Це і є головне виклик.
Загалом, технічна база вже є, головне — баланс між системним дизайном і управлінням ризиками.