From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AB1A7C7D for ; Fri, 3 Nov 2017 00:45:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com [209.85.128.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0B7B9196 for ; Fri, 3 Nov 2017 00:45:43 +0000 (UTC) Received: by mail-wr0-f174.google.com with SMTP id u40so1125159wrf.10 for ; Thu, 02 Nov 2017 17:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stampery.co; s=google; h=from:reply-to:subject:to:references:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zmH6X1Z58lPZly42ZgWrt/sonWCIYSwaXbDRtaickpw=; b=Jwn9qw+fYfoCrise6nHmeYIFB/gOhzf1rkcBjFLk5HLhZtIip71+Ex7q90KfrZpu9e X34NFvyJKP9Roxgs2OQezh+hGBpbkRLf7lh3T/UARIuBUxkCxBWil6sqrt11Nk5NZooY 3hgDhXVzLI8G2EiGzuHYbvujBiWiiu3YVyDRg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=zmH6X1Z58lPZly42ZgWrt/sonWCIYSwaXbDRtaickpw=; b=WOMeNRCeSmgcuAyCmf4wHdqmNDx6D+kyrYPesCrMNimmuLVBESlSFOMtt3xm6fWQOD wEzcPed9xl7T2WvM9+7h2FinU+tM7HIoOEBDesUwwNqzhOTh39bIrVCWHAE2iECnHspi QXQSM+okQ9urvWehUF5l1JQqboIhMhy54mx6Pq5vQZCc5XyeIWzqUBiGIFIkenb1+9w4 xWaqhbsDnTGOpUU6cYkW86Lxa00/2ADmtMhkjyBOZTjaObtlruK8U/oT1zXCyq5NRbxX LGZRUTGhFtqlUOZHs8yZyXgkVPWo+3tM98mkPHPlTzxJfd2y86MixECG1VjpYpzeOi3X LcOw== X-Gm-Message-State: AMCzsaUX4Eo2OeXudt2UFNkIRyIRwxaEyCSPgw/sTQlXgSEXl0n23OHo BQ6XZLJX9C/fUbC+22tpL4VuzKvLoro= X-Google-Smtp-Source: ABhQp+THIoJM6ekloT660fdsUdI7l/djK+Xh0sHn0/lXCEpN7f4IHv8vRHuMn6hbD7eqghR1md/9Kw== X-Received: by 10.223.152.199 with SMTP id w65mr4869845wrb.254.1509669942215; Thu, 02 Nov 2017 17:45:42 -0700 (PDT) Received: from [192.168.1.132] ([82.213.232.5]) by smtp.gmail.com with ESMTPSA id 195sm7028575wmj.3.2017.11.02.17.45.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 17:45:41 -0700 (PDT) From: "=?UTF-8?Q?Ad=c3=a1n_S=c3=a1nchez_de_Pedro_Crespo?=" X-Google-Original-From: =?UTF-8?Q?Ad=c3=a1n_S=c3=a1nchez_de_Pedro_Crespo?= Reply-To: adan@stampery.com To: bitcoin-dev@lists.linuxfoundation.org References: <052D6E20-7194-4645-B628-1B7B7FECF330@gmail.com> Organization: Stampery Message-ID: <76afed77-dd30-7a6d-8ee7-90b1396460d1@stampery.com> Date: Fri, 3 Nov 2017 01:45:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <052D6E20-7194-4645-B628-1B7B7FECF330@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 03 Nov 2017 01:41:23 +0000 Subject: Re: [bitcoin-dev] Simplicity proposal - Jets? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 00:45:44 -0000 Hi everyone, I agree that the paper could use some more details on the rationale behind "jets". After a couple of reads, I think I can "ELI5 them": As far as I understand, jets are a smart optimization that makes complex Simplicity contracts way cheaper to compute (ideally, comparable to Script or EVM). For this purpose, jets leverage the most important element of the Simplicity Bit Machine: the frames stack. In a Simplicity program, every expression or sub-expression can be thought of as a pure function that when applied on a certain initial read frame, results in the active write frame having a different value. This happens deterministically and without any side effects. So, if the Simplicity interpreter finds some expression whose result when applied upon a certain read frame is already known (because it has already been executed or it was somehow precomputed), it doesn't need to execute such expression step-by-step once again. Instead, it just need to write the known result to the active write frame. The paper suggests that at all times the interpreter knows the result of applying many common operations on all possible combinations of inputs in the range of 8 to 256 bits. In other words, the interpreter won't need to calculate "123 + 321" or compare "456 > 654 because the results of those expressions will be already known to it. These are stupid examples, but the savings are real for hash functions internals, elliptic curve calculations or even validation of signatures. As said before, this can help making Simplicity programs lighter on CPU usage, but it has many other benefits too: + Jets can replicate the behavior of complex chunks of Simplicity code with the guarantee that they can't introduce side effects. + Interpreter-bundled jets are formally proven. The more a Simplicity program relies on jets, the more it benefits from their safety. When proving the soundness of your program, you can just ignore the jets, assume they are valid and focus on your own logic. The paper also suggests that different sets of jets could make up different single purpose dialects, just like domain-specific languages bring richer vocabulary and semantics to the bare syntax and grammar of general-purpose languages. I hope Russel or Mark can correct me if I got something totally wrong. I must admit I really like this proposal and hereby declare myself a huge fan of their work :) -- Adán Sánchez de Pedro Crespo CTO, Stampery Inc. San Francisco - Madrid