CodeIP: A Grammar-Guided Multi-Bit Watermark for Large Language Models of Code
Batu Guan Yao Wan Zhangqian Bi Zheng Wang Hongyu Zhang Yulei Sui Pan Zhou Lichao Sun

Dynamic Beam Coverage for Satellite Communications Aided by Movable-Antenna Array
    Lipeng Zhu,  Member, IEEE,
	    Xiangyu Pi, Graduate Student Member, IEEE,
		Wenyan Ma, Graduate Student Member, IEEE,
		Zhenyu Xiao, Senior Member, IEEE,
		and Rui Zhang, Fellow, IEEE

	

	L. Zhu and W. Ma are with the Department of Electrical and Computer Engineering, National University of Singapore, Singapore 117583 (e-mail: zhulp@nus.edu.sg, wenyan@u.nus.edu).
	X. Pi and Z. Xiao are with the School of Electronic and Information Engineering, Beihang University, Beijing, China 100191. (e-mail: pixiangyu@buaa.edu.cn, xiaozy@buaa.edu.cn)
	R. Zhang is with School of Science and Engineering, Shenzhen Research Institute of Big Data, The Chinese University of Hong Kong, Shenzhen, Guangdong 518172, China (e-mail: rzhang@cuhk.edu.cn). He is also with the Department of Electrical and Computer Engineering, National University of Singapore, Singapore 117583 (e-mail: elezhang@nus.edu.sg).

    
=================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================


















As Large Language Models (LLMs) are increasingly used to automate code generation, it is often desired to know if the code is AI-generated and by which model, especially for purposes like protecting intellectual property (IP) in industry and preventing academic misconduct in education. Incorporating watermarks into machine-generated content is one way to provide code provenance, but existing solutions are restricted to a single bit or lack flexibility. We present , a new watermarking technique for LLM-based code generation. enables the insertion of multi-bit information while preserving the semantics of the generated code, improving the strength and diversity of the inerseted watermark. This is achieved by training a type predictor to predict the subsequent grammar type of the next token to enhance the syntactical and semantic correctness of the generated code. Experiments on a real-world dataset across five programming languages showcase the effectiveness of .





§ INTRODUCTION




Large Language Models (LLMs), particularly those pre-trained on code, such as CodeGen <cit.>, Code Llama <cit.>, and StarCoder <cit.>, have demonstrated great potential in automating software development. Notably, tools leveraging these LLMs, such as GitHub Copilot <cit.>, Amazon's CodeWhisperer <cit.>, and ChatGPT <cit.>, are revolutionizing the way developers approaching programming by automatically generating code based on natural language intent and the context of surrounding code. 



































While LLMs have demonstrated great potential in automated code generation, they also raise challenges about safeguarding the intellectual property (IP) of the model architectures, weights, and training data due to the enormous cost of training a successful LLM <cit.>. Additionally, there are growing concerns in educational settings about academic integrity with the use of generative AI <cit.>. An important measure for protecting the LLM IP and preventing academic misconduct is the ability to determine if a piece of code is generated by a particular LLM.


Watermarking techniques <cit.> offer a potential solution to determine the origin of machine-generated content. This technique is effective in safeguarding the IPs of Computer Vision (CV) and Natural Language Processing (NLP) models.
It works by inserting information within multimedia formats (such as images and videos) without perceptibly diminishing the original utility of the content. 
By incorporating data such as owner/user ID, it supports leakage tracing, ownership identification, meta-data binding, and fortifying against tampering.


Existing watermarking techniques for language models can be categorized into two groups: hard and soft watermarks.
A hard watermark is typically inserted by utilizing the masked language models (e.g., BERT <cit.> and RoBERTa <cit.>) to replace tokens in generated content with synonyms. However, a hard watermark exhibits consistent patterns for different model inputs, compromising the protection performance. 
On the contrary, the soft watermarks are inserted during content generation, typically via manipulating the sampling probability distribution over the vocabulary during the decoding process of LLMs <cit.>. 





Recently, several attempts have been made towards watermarking LLMs for code generation, 
predominantly centered on two distinct approaches:

generating a one-bit watermark to discern the machine-generated nature of the code <cit.> or embedding a hard watermark through a semantic-equivalent transformation of the generated code <cit.>. However, a one-bit message can carry little information and is inadequate to preserve enough copyright information like the vendor ID of an LLM. 

Moreover, the implementation of a hard watermark does not offer robust protection, as the easily detectable nature of the hard-coded watermarking pattern undermines its effectiveness.




To this end, this paper puts forward a grammar-guided multi-bit soft watermarking method, termed , to protect the IPs associated with LLMs during the code generation process. 


Specifically, following <cit.>, we first insert the watermark message based on the probability logit of LLMs during the code generation process.

As this strategy has the potential to interfere with code semantics throughout the code generation process, we propose to incorporate grammar information into the process of generating watermarked code. This is achieved by training a type predictor to predict the subsequent grammar type of the next token, thereby enhancing the semantic correctness of the generated code.






Figure <ref> shows an example to illustrate the effectiveness of our introduced grammar information in comparison to the baseline model.


In this example, our objective is to insert the multi-bit message (model name) “” (corresponding to the ASCII value of “”) into its generated code. 

It is evident that, in the absence of grammar guidance, the model inaccurately predicts the next token as “”. 
However, the grammar analysis indicates that the succeeding token is expected to be a keyword. Our , which incorporates grammar constraints into the logit of LLMs, consistently tends to predict the correct token “”.

This capability preserves the semantic correctness of the code during the insertion of watermarks into LLMs.




















We assess the performance of  by incorporating watermarks into a diverse real-world dataset that encompasses five programming languages, namely Java, Python, Go, JavaScript, and PHP. The experimental results validate the efficacy of our proposed approach to watermarking, demonstrating an average extraction rate of 0.95. Importantly, our approach maintains the utility of the generated code, exhibiting a 50% reduction in CodeBLEU losses compared to the baseline model that lacks grammar constraints.




This paper makes the following contributions.


    
  * 
    
    It is the first to study the problem of embedding the soft multi-bit watermarks into LLMs of code during the code generation process.
    
  * It presents a new method that utilizes the grammatical information of programming languages to guide the manipulation of probability logits in LLMs, thereby preserving the utility of watermarked code.
    
    
    




 

  
Data Availability.
 
All experimental data and source code used in this paper are available at  <cit.>.






































§ PRELIMINARY




 §.§ Code Generation






LLM-based code generation produces source code from high-level specifications or prompts.
Typically, these specifications (prompts) are conveyed through natural-language descriptions, supplemented by partial code elements such as function annotations and declarations, which are provided by users.
Formally, let ρ denote a prompt, which can be
tokenized into a sequence of tokens {w_1, w_2, … ,w_|ρ|}, where |·| denotes the length of a sequence.
Let 𝒱 denote the vocabulary used for mapping each token to corresponding indexes.









Given a language model p_LM, the probability of the next token, conditioned on a prompt and a series of the previous generated tokens w_1:i, can be formulated as follows.

    ℒ_LM=p_LM(w_i) = softmax ( p_LM(w_i|ρ, w_1:i)  ) .


Here, p_LM(w_i) denotes the probability distribution over the entire vocabulary 𝒱, generated by the LM. We also call the probability distribution produced by the LM as model logit.
In this paper, the LM will always be an autoregressive Transformer <cit.> pre-trained on source code, akin to the models in the GPT family, including Code Llama <cit.> and StarCoder <cit.>.



Following this, the subsequent token w_i is sampled from p_LM(w_i) using specific sampling strategies, such as multinomial sampling <cit.> or greedy sampling <cit.>.
In this paper, we adopt the greedy sampling strategy. Therefore, the next token will be sampled based on the following equation: w_i = w ∈𝒱maxlog p_LM(w).

































 §.§ The Problem: Watermarking the Code






In this paper, our goal is to insert a multi-bit watermark message into a code snippet during the generation process of LLMs.

Typically, the watermarking algorithm comprises two stages: the watermark inserting stage and the watermark  stage.








During the process of inserting a watermark into the generated code, the initial consideration involves determining the specific message m to be inserted as the watermark.

In practice, the model provider of an LLM can formulate a message, e.g., owner ID, to safeguard its model copyright.



It is noteworthy that while the initial content of message m may encompass any characters, it undergoes conversion into a unique number before insertion.



Specifically, given the prompt ρ and a watermark message m as inputs, the INSERT module produces a watermarked code




C = INSERT(ρ, m) .



During the watermark  stage, 

given an input snippet of code C, our expectation is that the  module EXTRACT will produce its predicted watermark message


    m = EXTRACT(C) .








In the context of this formulation, the primary objectives of our watermarking for LLMs of code are twofold: 
1) to accurately insert the intent message as a watermark, and 2) to preserve the utility of the code without loss of semantics.










































§ 








In Figure <ref>, we present an overview of our proposed , which inserts a watermark into code generated by an LLM.














The  comprises two distinct stages: watermark insertion, and grammar-guided watermarking.

Initially, leveraging the decoding mechanism of existing LLMs, we use ℒ_LM to denote the likelihood of each token in the vocabulary 𝒱 as inferred by the LLM itself. 
Subsequently, during the watermark insertion stage (cf. Sec. <ref>), we incorporate the watermark message using a logit value ℒ_WM calculated to measure its influence on 𝒱. 


Moreover, we present a novel application of Context-Free Grammar (CFG) and introduce a logit (denoted as ℒ_TP), which signifies the probability associated with the grammatical type of the subsequent token, to guide the watermark insertion during the code generation process (cf. Sec. <ref>). 














 §.§ Watermark Insertion




Following <cit.>, 

we insert the watermark into the generated code by modifying the probability distribution over the entire vocabulary 𝒱 as the LLM generates the next token.




We first select a set of tokens from the vocabulary using a hash function.

Based on the selected tokens, we compute the watermark logits, representing the likelihood of embedding the watermark message within each respective token.






  
Vocabulary Selection.



Following <cit.>, the insight of inserting watermarks into code lies in selecting a set of tokens in the vocabulary under the control of the watermark message and enhancing their probability of generation during the stage of LLM decoding. 







We employ a hash function ℋ to select tokens from the vocabulary 𝒱.

Specifically, assuming that LLM is generating the i-th token and the previous generation is denoted as [w_1,w_2, ⋯, w_i-1], with watermark message represented by m. For any given token w in 𝒱, the hash function will take (w,m,w_i-1) as input and map it to either 0 or 1. 

We consider tokens w that satisfy ℋ(w,m,w_i-1) = 1 as selected tokens, and our objective is to enhance their likelihood of being chosen by the LLM.






  
Watermark Logit.







To augment the likelihood of generation, we calculate an additional logit referred to as the watermark logit ℒ_WM and incorporate it into the existing model logit ℒ_LM.


The implementation of the watermark logit ℒ_WM relies on the outcomes of vocabulary partitioning. Assuming that the current LLM generates the i-th token wi, preceded by the last token w_i-1, and denoting the watermark information as m,



the watermark logit is computed as follows:

    ℒ_WM   =  log p_WM( w_i| m, w_i-1) 
        =1,    ℋ(w,m,w_i-1) = 1 
     0,    ℋ(w,m,w_i-1) = 0


















Here h denotes a hash function which 

outputs a binarization value 0 or 1. p_WM denotes the probability distribution over the entire vocabulary 𝒱, which conveys analogous implications to that of p_LM.
By assigning a value of 1 to ℒ_WM for those selected tokens whose resultant computation via the hash function equals 1, we can effectively enhance the likelihood of such tokens being preferentially chosen during the decoding stage of LLM.
































 §.§ Grammar-Guided Watermarking 






As previously mentioned, conventional watermarking methods, which randomly insert a message by perturbing the generation process for each token, often result in the disruption of the semantics within the generated code.


We posit that the generated code ought to adhere to the grammatical rules of the programming language. Consequently, we propose the integration of grammar constraints as a guiding principle in the code generation process. This inclusion is envisioned to maintain the utility of watermarked generated code.






  
Context-Free Grammar (CFG).







A CFG serves as a formal system for describing the syntax of programming languages, and possesses sufficient expressiveness to represent the syntax of most programming languages <cit.>.


Typically, for a segment of code, a lexer, e.g., ANTLR <cit.>, can transform it into a sequence of lexical tokens. Subsequently, under the constraints of CFG rules, we can infer the potential type of the subsequent lexical token. For instance, as illustrated in Figure <ref>, after transforming the original code “” into the sequence of lexical tokens, we can use CFG to infer the potential type of the subsequent lexical token as either “” or “”, which could be helpful in the scenario of code generation. 









Nonetheless, despite the constraints that CFG imposes on code, its direct application to the field of code generation still presents certain challenges. 


As demonstrated in the example of Figure <ref>, a CFG is capable of analyzing potential types for the subsequent lexical token. However, when multiple token types are considered as valid next token types, CFG's utility in aiding code generation tasks becomes significantly limited, for it lacks the capacity to calculate the probability distribution among these possible token types. Hence, we train a lexical token-type predictor and intend to utilize it as a substitute for the CFG. 








  
Lexical Token Type Predictor.


We train a neural network to predict the lexical type of the next token. 
In particular, given the prompt and previously generated tokens, we initially employ a lexer to transform the given data into a sequence of lexical token types. Subsequently, this sequence is inputted into the predictor. The predictor then forecasts a token type that will be outputted as the most probable lexical token type for the subsequent token.






In the context of code generation with LLMs and its prompt denoted as ρ, assuming that the LLM is in the process of generating the i-th token when the generated code denoted as G, for any given code snippet denoted as S = [ρ; G_1:i], where [·;·] denotes the concatenation of two elements, it is feasible to extract its token sequence T = Lexer(S) = [τ_1, τ_2, …, τ_l] via lexical analysis, where τ∈𝒯 denotes the lexical token type and l denotes the length of lexical token sequence. Then an LSTM <cit.> is adopted to serve as the type predictor and to predict the token type of the subsequent token by inputting the token sequence T, as follows:


    τ_l+1 = TP(T)= LSTM(τ_1, τ_2, …, τ_l)) .

Other neural networks, such as the Transformer <cit.> can also be applied and we leave the exploration of other neural networks as our future work. 




  
Type Predictor Logit.
In order to mitigate the negative impact of watermarking on code utility, it is imperative to leverage our type predictor during the watermark insertion process, which is also the LLM decoding period. This necessitates transforming the predictive outcomes of the type predictor into a form of logit that can be added onto model logits. We name the new logit as type predictor logit, which can also be represented as ℒ_TP.



The type predictor logit is a probability distribution of tokens within vocabulary 𝒱. Consequently, it becomes imperative to construct a dictionary in advance that associates each type of lexical token with potential LLM tokens corresponding to that particular type. For instance, the  lexical token type encompasses LLM tokens such as “”, “”, and “”, while the  lexical token type incorporates LLM tokens including “”, “”, “”, “”, and so forth. We denote this dictionary by Φ: 𝒯↦𝒱. Thus, ℒ_TP can be calculated as follows:



    ℒ_TP=log p_TP(w_i | [ρ; G_1:i]) = 1,     w_i ∈Φ(τ_l+1) 
     0,     w_i ∉Φ(τ_l+1)

Here, ρ represents the prompt input into the LLM, and G denotes the pre-existing generated code. At this juncture, we are in the process of generating the i-th token w_i.





















 §.§ Combining the All

The subsequent section will present the watermark inserting formula corresponding to Figure <ref>, along with the ultimate watermark embedding algorithm.

    w_i = max _w ∈𝒱{ℒ_LM + βℒ_WM + γℒ_TP} .


In accordance with the settings established in the preceding sections, we posit that LLM is generating the i-th token. Herein, β and γ represent hyperparameters for LLM logit ℒ_LM, watermark logit ℒ_WM, and type predictor logit ℒ_TP respectively.



































 §.§ Watermark Extraction



In the watermarking phase, we employ ℒ_WM to insert a watermark w into the output G. Our strategy for watermark extraction involves enumerating all possible instances of m, recreating the process of watermark insertion, and identifying the instance of w that maximizes ℒ_WM, as follows: 





    m = m^'max{∑_i=1^Llog p_WM(w_i| m^', w_i-1)} ,





where L denotes the length of the token sequence in the generated code G. 
















































§ EXPERIMENTAL SETUP



























 §.§ LLMs and Dataset



To validate the effectiveness of our , we choose three prominent LLMs: Code Llama <cit.>, StarCoder <cit.>, and DeepSeek Coder <cit.> as our target models. 
We insert the watermark into the code generated by these selected models.


Note that, these models exist in different versions, each characterized by varying model sizes. In our experiments, we choose to employ the 7B model size, limited by the computational resources.
We select Java, Python, Go, JavaScript and PHP from CodeSearchNet <cit.> dataset and use the docstrings and function declarations as prompts. For each prompt, the LLMs will generate the next 200 tokens.

Note that here we do not adopt HumanEval <cit.> and MBPP <cit.> datasets as our evaluation datasets. This is because their code length is generally too short and not suitable for inserting watermarks. The relationship between the length of generated code and the extraction rate is studied in Sec. <ref>.





















 §.§ Implementation Details


The default hyperparameters are configured as follows. For all three LLMs, we implement a temperature of 0.75, a repetition penalty of 1.2, and no repeat n-gram size of 10. Given the distinct training processes of various LLMs, we establish the parameters (β,γ) as (5,3) for Code Llama and StarCoder, (6,4) for DeepSeek Coder. The type predictor is an LSTM model, which encompasses an embedding layer characterized by an embedding dimensionality of 64. The hidden state dimensionality of the LSTM is 128. In our experiment, we train a type predictor for each language involved, given the distinct grammatical structures inherent to each language.
All the experiments in this paper 

are conducted on a Linux server with 128GB memory, with a single 32GB Tesla V100 GPU.







 §.§ Evaluation Metrics



To evaluate the effectiveness of watermarking, one objective is to assess whether the watermark can be detected from the generated code.

Specifically, we select 100 functions from the dataset for each programming language and extract the docstrings and declarations of each function to serve as prompts for LLMs generation.




We employ the extraction rate of watermarks as a metric to measure the efficacy of watermarking, reflecting the percentage of watermarks successfully extracted from the embedded code.

To validate the utility of watermarked code, we adopt the CodeBLEU <cit.> metric, which has been widely adopted in the evaluation of code generation.

Note that, here we do not adopt the Pass@k metric <cit.>, which has been widely adopted to evaluate the LLMs for code generation. This is because the test cases are missing in our used CodeSearchNet dataset.
















§ RESULTS AND ANALYSIS



 §.§ Extraction Rate of Watermarks







Table <ref> shows a comparison among different kinds of watermarking strategies. 


Generally, under both watermarking strategies, the extraction rates consistently surpass 0.90 on most programming languages, indicating the efficacy of our watermarking techniques in the context of LLMs for code generation.



Using DeepSeek Coder as a case in point, our watermarking strategy, both with and without the type predictor, demonstrates an impressive extraction rate of 0.99 for Java and 1.00 for PHP.

These results are consistent with our initial expectations, as the type predictor is designed to prioritize the preservation of the utility of the generated code.








 §.§ Watermark vs Code Quality





We further explore the impact of watermarking strategies on the utility of generated code.

Table <ref> illustrates the overall performance of different LLMs when paired with distinct logits (“w/ WM + w/o TP” and “w/ WM + w/ TP”), measured by the CodeBLEU score.




From this table, it is evident that the exclusive use of watermark logit leads to a notable decrease in CodeBLEU scores for code generation across various models and languages, and with the subsequent incorporation of the type predictor logit, a distinct resurgence in CodeBLEU scores is observed across most settings. Notably, in Java, Go, and JavaScript, the impact on CodeBLEU generation resulting from the simultaneous application of both logits (i.e., watermark logit and type predictor logit) is only half as pronounced as that arising solely from the use of watermark logit. This emphasizes the significant efficacy of the type predictor in preserving code semantics.



 §.§ Parameter Analysis





The impact of parameter β. 

We conduct an experiment on the variation in extraction rates when adjusting the β value under three distinct LLMs for two programming languages, namely Java and Go, as shown in Figure <ref>.

It can be seen that as β continues to increase, the extraction rate of watermarks is also constantly increasing. When β exceeds 5, a extraction rate of approximately 0.9 can essentially be achieved, which is relatively ideal. It indicates that watermark logit has a positive effect on whether watermarks can be detected.















The impact of parameter γ. 

We conduct experiments on three distinct LLMs by varying the γ value, aiming to investigate the variations in extraction rates pertaining to two programming languages: Java and Go.


The experimental results, as depicted in Figure <ref>, reveal a noteworthy trend. The initial augmentation of γ visibly improves the quality of the generated code. Nevertheless, as the augmentation progresses beyond a certain threshold, a discernible decline in CodeBLEU becomes evident.

One plausible explanation for this inconsistency may stem from the inherent contradiction in tokenization, namely, the disparity between prevalent tokenization methods utilized by LLMs (e.g., WordPiece <cit.> and BPE <cit.>), and those employed by lexers.


For example, the LLM subtokens “” and “”, when combined, can constitute the lexical token  which can be recognized during lexical analysis. And assuming the generated code to be “”, the subsequent LLM subtoken to be generated is most likely to be “”, thereby rendering the generated code as “”. However, from the perspective of a lexer, the type of “” could potentially be classified as type “”, so the calculated lexical token type will be “”, thereby selecting “”. Hence, the generation of code will be transformed into “”. This contradiction caused by different segmentation methods between LLM tokenizer and lexical analysis can also lead to performance degradation when γ is high.


















The impact of generated code length. 


We also investigate the influence of generated code length, measured in terms of the number of tokens produced, on the effectiveness of watermark insertion. Our findings reveal a positive correlation between code length and the successful extraction rate, as depicted in Figure <ref>. This observation underscores that the successful extraction rate of our watermark remains contingent on the length of the generated code. Specifically, shorter lengths of generated code lead to diminished distinctions between watermarked and non-watermarked code, consequently presenting a heightened challenge in detecting watermarks within such code.











































 §.§ Resistance to Crop Attack
 

To underscore the robustness of our watermarking strategies, we consider a hypothetical scenario where developers use only a portion, rather than the entire generated code, to undermine the watermark—a situation termed a “Crop Attack”. This involves subjecting the generated code to crop rates of 0.25 and 0.5, representing the removal of 25% and 50% of the code, respectively. The results are presented in Table <ref>. Examination of the table reveals that, in most cases, our watermark's effectiveness only experiences a slight reduction under such rigorous attacks. These findings strongly indicate that our watermark exhibits notable resistance to crop attacks, demonstrating its inherent robustness.



































§ RELATED WORK







  
LLM-based Code Generation.



The roots of code generation can be traced back several decades <cit.>.
Recently, LLMs especially those pre-trained on code, such as DeepSeek Coder <cit.>, Code Llama <cit.>, CodeGen <cit.>, StarCoder <cit.>, and CodeGeeX2 <cit.>, have emerged as dominant forces in code generation. Leveraging the capabilities of these LLMs, several commercial tools are reshaping the programming landscape for developers, including GPT-3.5 <cit.>, Gemini <cit.>, GitHub Copilot <cit.>, and Tabnine <cit.>, ushering in a new era of innovation.













  
Software Watermarking. 
The software watermarking problem has been studied since 1996 by <cit.>, who altered code block or operand order to insert watermarks. 
<cit.> proposed a software watermark method based on graph coloring problem and graph structure of the code, which was further developed by <cit.>, <cit.> and <cit.>. These rule-based early methods are often constrained by the usage scenarios and various attack techniques.
<cit.> has also proffered a methodology that entails the transformation and reorganization of code to uphold semantic integrity while concurrently resisting reverse engineering. 


Recently, several works <cit.> have been focusing on watermarking the code generated by LLMs.


They utilized a post-processing approach, whereby watermarks are inserted through transformations applied to the code subsequent to its generation by the model. 
However, these techniques present several limitations including their specificity for a single language, susceptibility to counterfeiting upon watermark method disclosure, restricting their applicability.









  
Machine Generated Text Identification. 




The task of identifying machine-generated text has always been of paramount importance. 


An intuitive approach is to treat it as a binary classification task, accomplished by training a model <cit.>. 

Another approach is to identify model-generated text by detecting features of the generated text. <cit.> distinguished texts by detecting detectable artifacts in the generated text, such as sampling methods, top-k probabilities, etc.

In 2023, a novel method was introduced by <cit.> suggesting the inserting of watermarks into text during the model inference period. The authors applied a hash function and a random number generator to divide candidate tokens into groups, allowing watermark extraction by those aware of the rule. 
<cit.> extended this method to code generation with threshold-controlled watermark inclusion. 




















§ CONCLUSION









In this paper, we propose  to watermark the LLMs for code generation, with the goal of safeguarding the IPs of LLMs. 
We insert watermarks into code generated by the model, and introduce grammatical information into the watermark generation process by designing a type predictor module to safeguard the utility of generated code.

Comprehensive experimental findings affirm that  exhibits a notable extraction rate, excels in safeguarding code semantics, and demonstrates a degree of resilience against attacks.
In our future work, we plan to persistently advance towards more secure LLM-powered software engineering through the continuation of our research.




§ LIMITATIONS



In our experiment, we adopt CodeBLEU for evaluation, which is a commonly used metric in assessing the quality of code generation. In our future work, we will employ additional evaluation metrics to assess the experimental results.

Furthermore, the experiments have substantiated that our watermark exhibits a certain degree of robustness under crop attacks, as this is the most easily implemented attack method in model copyright scenarios. Other forms of attacks such as variable name obfuscation could potentially degrade the readability of generated code, thus making them less likely to be employed in attacks aimed at infringing model copyrights, which is an assault we aim to prevent. We will persistently investigate and enhance the robustness of our watermark to make it applicable for more protection scenarios.








langley00








§ LEXICAL TOKEN TYPE

Despite the diversity in syntax among various programming languages, a consistency remains at the lexical analysis level. That is, the types of tokens parsed out by lexical analysis are fundamentally similar. The text box below presents potential token types that may be parsed following lexical analysis.


.9





§ LEARNING THE TYPE PREDICTOR

Formally, the type predictor accomplishes the task of the next lexical token prediction. We adhere to conventional training methodologies for this particular task to train it. For a given programming language, we postulate that the collected code dataset of this particular language is denoted as 𝒟, and each segment of code within this dataset as d ∈𝒟.
To facilitate the acquisition of pertinent language grammar by the type predictor, we initially employ a lexer specific to that language to transform each instance of d into a corresponding lexer token sequence. Taking into account that the possible token type of the subsequent word is typically associated with the types of nearby tokens, for predicting the type of the i-th token, we extract n preceding token types from the sequence to predict this i-th token type. Hence, for the dataset 𝒟, our learning objective can be articulated as follows.

    𝒥(𝒟) = ∑_d ∈𝒟∑_i=n^|T_d|log p_LSTM(l_i | l_(i-n):i)

where 𝒥 is the loss function utilized during the training of type predictor, and |T_d| denotes the length of lexical token type sequence of original code d.



§ CODEBLEU

The CodeBLEU metric can be depicted as follows. 



    CodeBLEU    = η·BLEU + λ·BLEU_weight
        + μ·Match_ast + ξ·Match_df






Here, BLEU is computed utilizing the conventional BLEU method as delineated by <cit.>. The term BLEU_weight refers to a weighted n-gram match that is derived from juxtaposing hypothesis code and reference code tokens with varying weights. Furthermore, Match_ast signifies a syntactic AST match which delves into the syntactic information inherent in the code. Lastly, Match_df denotes a semantic dataflow match that takes into account the semantic congruity between the hypothesis and its corresponding reference.

In our experiments, we adopt the parameters recommended by <cit.> in their original paper, namely (η, λ, μ, ξ) = (0.10,0.10,0.40,0.40).



§ CASE STUDY

In Figure <ref>, we demonstrate examples of the generation code of LLM under three different strategies(w/o WM + w/o TP, w/ WM + w/o TP, and w/ WM + w/ TP), and the watermark message is the number “”. The prompt contains the docstring and declaration of the function.

From Figure <ref> we can see that when watermark logit and type predictor logit are not applied during the decoding stage of LLM, it generates some normal Python code, and in this scenario, no watermark is inserted in the code because watermark logit is not applied. When only the watermark logit is added to the model logit, the LLM starts to generate large sections of comments, which is meaningless to the implementation of the function. The reason is supposed to be that the watermark logits enhance the generation probability of comment symbols like “” and “”, who then affect the LLM to generate comments rather than codes, which do harmness to code utility. Subsequently, when type predictor logits are also added to the model logits, the generation code of LLM resumes to normal and generates complete code to implement the function shown in the prompt.

As illustrated in Figure <ref>, the LLM generated nearly identical outputs under the three strategies. In this particular instance, no conspicuous grammatical errors were detected, and the outputs of both strategies - w/ WM + w/o TP and w/ WM + w/ TP - bear a striking resemblance to the output of w/o WM + w/o TP strategy. This case demonstrates that the watermarks we incorporated exert minimal influence on the output of LLM.

As depicted in Figure <ref>, w/ WM + w/o TP leads to meaningless generations due to the absence of grammar guidance, when w/ WM + w/ TP generates something similar to w/o WM + w/o TP, and also insert watermark “1012” into it. We posit that the observed outcome can be attributed to the fact that watermark logits have potentially increased the probability of erroneous type tokens being selected by LLM. Furthermore, it is discernible that once an incorrect type of token is chosen, the model's output will continually be misguided. For instance, upon the model's erroneous output of the token “” due to the influence of watermark logits, it is anticipated that a complete function declaration will be subsequently generated by the model, thereby leading to a sustained impact on code semantics, and the generation of symbol “” will lead to the generation of comments, which also shows the misleading effect watermark logit have on code generation task. As it is also shown in the Figure, when type predictor logit is applied, such circumstances are unlikely to occur.

























